Wikibooks:Requests for deletion

<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.11/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.11/ http://www.mediawiki.org/xml/export-0.11.xsd" version="0.11" xml:lang="en">
  <siteinfo>
    <sitename>Wikibooks</sitename>
    <dbname>enwikibooks</dbname>
    <base>https://en.wikibooks.org/wiki/Main_Page</base>
    <generator>MediaWiki 1.47.0-wmf.14</generator>
    <case>first-letter</case>
    <namespaces>
      <namespace key="-2" case="first-letter">Media</namespace>
      <namespace key="-1" case="first-letter">Special</namespace>
      <namespace key="0" case="first-letter" />
      <namespace key="1" case="first-letter">Talk</namespace>
      <namespace key="2" case="first-letter">User</namespace>
      <namespace key="3" case="first-letter">User talk</namespace>
      <namespace key="4" case="first-letter">Wikibooks</namespace>
      <namespace key="5" case="first-letter">Wikibooks talk</namespace>
      <namespace key="6" case="first-letter">File</namespace>
      <namespace key="7" case="first-letter">File talk</namespace>
      <namespace key="8" case="first-letter">MediaWiki</namespace>
      <namespace key="9" case="first-letter">MediaWiki talk</namespace>
      <namespace key="10" case="first-letter">Template</namespace>
      <namespace key="11" case="first-letter">Template talk</namespace>
      <namespace key="12" case="first-letter">Help</namespace>
      <namespace key="13" case="first-letter">Help talk</namespace>
      <namespace key="14" case="first-letter">Category</namespace>
      <namespace key="15" case="first-letter">Category talk</namespace>
      <namespace key="102" case="first-letter">Cookbook</namespace>
      <namespace key="103" case="first-letter">Cookbook talk</namespace>
      <namespace key="108" case="first-letter">Transwiki</namespace>
      <namespace key="109" case="first-letter">Transwiki talk</namespace>
      <namespace key="110" case="first-letter">Wikijunior</namespace>
      <namespace key="111" case="first-letter">Wikijunior talk</namespace>
      <namespace key="112" case="first-letter">Subject</namespace>
      <namespace key="113" case="first-letter">Subject talk</namespace>
      <namespace key="710" case="first-letter">TimedText</namespace>
      <namespace key="711" case="first-letter">TimedText talk</namespace>
      <namespace key="828" case="first-letter">Module</namespace>
      <namespace key="829" case="first-letter">Module talk</namespace>
      <namespace key="1728" case="first-letter">Event</namespace>
      <namespace key="1729" case="first-letter">Event talk</namespace>
    </namespaces>
  </siteinfo>
  <page>
    <title>Wikibooks:Requests for deletion</title>
    <ns>4</ns>
    <id>385</id>
    <revision>
      <id>4657116</id>
      <parentid>4656445</parentid>
      <timestamp>2026-08-11T00:01:19Z</timestamp>
      <contributor>
        <username>JJPMaster (bot)</username>
        <id>3488561</id>
      </contributor>
      <minor />
      <comment>Bot: Removing archived requests from main RfD page</comment>
      <origin>4657116</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="45391" sha1="5yo0vl06xwugxmqu5lz1yi9o019dvj4" xml:space="preserve">__NEWSECTIONLINK__
[[Category:Wikibooks deletion|{{PAGENAME}}]]
{{Discussion Rooms}}
{{TOCleft}}
{{shortcut|WB:RFD}}
{{Requests for deletion/New deletion}}
{{Requests for deletion/Deletion intro}}
&lt;!-- New deletion nominations go at the bottom of page. --&gt;

== [[Salute, Jonathan!]] and its translations ==

&lt;div style=&quot;column-count: 7;&quot;&gt;
* [[Salute, Jonathan!|Interlingue/Occidental]] ([[w:en:Occidental|w]], original)
* [[Òla, Ionatà!|Audià]]
* [[Holo, Jonathan!|Cristianés]]
* [[Terve, Jonathan!|Ekumenski]]
* [[Hej, Jonathan! (Germanisch)|Germanisch]]
* [[Salom, Jonatan!|Globasa]]
* [[Àlŏ, Jonathan!|Guosa]] ([[w:en:Guosa|w]])
* [[Salut, Jonathan!|Idiom Neutral]] ([[w:en:Idiom Neutral|w]])
* [[Saluto, Jonathan! (Ido)|Ido]] ([[w:en:Ido|w]])
* [[Hallo, Jonathan!|Interlingua]] ([[w:en:Interlingua|w]])
* [[Salut, Jonathan! (Interocidental)|Interocidental]]
* [[Bune Ğonatan!|Lingaust]]
* [[Oila, Jonatan!|Lingue Simple]]
* [[Haloo, Jonatan!|Lingwa de Planeta]] ([[w:en:Lingwa de Planeta|w]])
* [[Sin Chao, Jonathan!|Masa Tang]]
* [[Salut, ionatano!|Meteza]]
* [[Salu, Jon!|Mini]]
* [[Hay, Jonathan!|Mirad]]
* [[Hai, Jon!|Monav]]
* [[Sesan Jon!|Monkel]]
* [[Salam, Jonathan!|Mundeze]]
* [[Dag, Jonathan!|Negerhollands]] ([[w:en:Negerhollands|w]])
* [[Salut Jonathan!|Neo]] ([[w:en:Neo|w]])
* [[Hej, Jonathan!|Nordien]]
* [[Saluto, Jonathan!|Novial]] ([[w:en:Novial|w]])
* [[Salute, Jonathan! (Novlingue)|Novlingue]]
* [[Alo, Jonathan!|Numo]]
* [[Hela, Jonathan!|Proyo]]
* [[Salute, Jonathan! (Romanica)|Romanica]] ([[w:en:Romanica|w]])
* [[Simi, Jonathan!|Solresol]] ([[w:en:Solresol|w]])
* [[Toki a, jan Jonatan!|Toki Pona]] ([[w:en:Toki Pona|w]])
* [[Glidis, o Jonathan!|Volapük]] ([[w:en:Volapük|w]])
&lt;/div&gt;

There are a couple of issues here:

# Beyond their introductions, all of these books are written in languages which are not English, making them out of scope for the English Wikibooks.
# All but one of these books are in fact written in constructed languages, most of them in recently created conlangs. In some cases (e.g. [[Sin Chao, Jonathan!]]), I can't find any reliable sources describing the target language outside of the translation itself.
# Most of the translations (i.e. other than [[Salute, Jonathan!]] itself) were abandoned within the first five or so chapters (out of 100); none of them are complete, and there seems to be little effort to complete any of them.

While I recognize that this is an unusual project, and potentially one which could have some value, it's not at all clear to me that the English Wikibooks is the right place for it. — [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 00:24, 29 September 2024 (UTC)

: I'm really not sure what to do about these ones. While I recognize that this approach is certainly one method of teaching a language, I'm not sure that it constitutes an educational textbook. We do require that the English Wikibooks be written in English—for language-learning books, this typically means that the instructional parts are in English while the exercises are in the language being taught. I do think that if the language doesn't have much supporting evidence outside the book itself, it can safely be deleted. — [[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 01:01, 29 September 2024 (UTC)

: Author of the book here. I originally wanted to put it in the Interlingue Wikibooks https://ie.wikibooks.org/wiki/Principal_p%C3%A1gine but it somehow got locked when I wasn't paying attention and so I ended up putting it here. Getting it unlocked requires going through the process of starting an Incubator and all the rest so I opted for here and then started putting some English-only content once it was done. It's sort of in the same vein as books like Lingua Latina per se Illustrata that have separate versions with teacher notes and whatnot. [[Salute, Jonathan!/Capitul 1 - with notes]] After it was done the auxlang community really took to it which was a nice surprise. I think Ido has the largest number of chapters at the moment at 15.
:If the vast content of this book could be used to justify a quick reopening of the Interlingue Wikibooks to move it there, I'd love to do that. I imagine that an incubator with 100+ book chapters would be enough to open a Wikibooks and that's what this is. — [[User:Mithridates|Mithridates]] ([[User talk:Mithridates|discuss]] • [[Special:Contributions/Mithridates|contribs]]) 06:02, 29 September 2024 (UTC)

: Ah, I just realized that we do have a proposal to reopen the Interlingue Wikibooks: https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikibooks_Interlingue along with an Incubator page here. https://incubator.wikimedia.org/wiki/Wb/ie/Principal_p%C3%A1gine
: How easy would it be to migrate the entirety of Salute Jonathan to there? — [[User:Mithridates|Mithridates]] ([[User talk:Mithridates|discuss]] • [[Special:Contributions/Mithridates|contribs]]) 06:30, 29 September 2024 (UTC)

:: Hi @[[User:Mithridates|Mithridates]]! I'm not sure how incubator projects work, but I fully support migrating these books there. You may want to inquire over there and link to this discussion to support your request to move the content over there. Cheers! — [[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 13:16, 29 September 2024 (UTC)

::: Hi! Actually I have a third idea to propose after thinking about this again today (haven't been here much since I finished the book): I noticed that there is more English content than I remember and that might make it an awkward fit for the Interlingue Wikibooks. I definitely agree that having all the auxlang translations for new auxlang projects goes well beyond the scope of this Wikibooks. Finally, there are some auxlangs that are notable with their own Wikipedias.
::: So the idea is the following:
:::# Leave the original here and I can continue the work on the version with English notes and grammar. That will make it the same as Lingua Latina per se Illustrata, English by the Nature Method, Athenaze and all the rest.
:::# The Interlingua one can move to the Interlingua Wikibooks (maybe Romanica too if they want as it is sort of a dialect of Interlingua).
:::# For Ido and Lingua Franca Nova which have a Wikipedia but not a Wikibooks, I'm a little bit unsure...technically they could have their own version like the original one but would require English explanations. I could let them know and see if they are willing to do so and see what they think (work on adding English to the books vs. move the content elsewhere).
:::# The rest can move to a Github repo, then be deleted, and the front page of this book can have a single link to the repo.
::: Any thoughts on that? Adding the extra English content will be easy as it is my book and I know it inside and out.
::: Edit: [https://en.wikibooks.org/wiki/Salute,_Jonathan!/Grammar_(pronouns) this page] I just added.  — [[User:Mithridates|Mithridates]] ([[User talk:Mithridates|discuss]] • [[Special:Contributions/Mithridates|contribs]]) 13:50, 29 September 2024 (UTC)

:::: Thanks for taking the time to consider this! Here are my responses/questions:
::::* Is the original [[Salute, Jonathan!]] (Occidental)? Since that one is quite fleshed out, I agree that if you edit it so the primary language of the book (e.g. headers, instructions, etc) are written in English while leaving the actual story in Occidental, it would be okay and fit in more with instructional language textbooks.
::::* For your points 2 and 3, I'm not sure how those other projects work, so I'll leave it up to them. I'm not quite sure why they would need to move, since in theory they could be revised with English as the language of instruction? Although, they have been left incomplete for a long time.
::::* For your point 4, I have no problem with that. Cheers! — [[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 16:51, 29 September 2024 (UTC)

::::: Hello again, it's the weekend so I have a bit more time to work on this. I've decided to merge the extra content from the following five chapters since the difference is fairly small and the original chapters should now have this English content. Could you delete these five pages now that they are no longer needed? [[User:Mithridates|Mithridates]] ([[User talk:Mithridates|discuss]] • [[Special:Contributions/Mithridates|contribs]]) 14:02, 5 October 2024 (UTC)
::::: [[Salute, Jonathan!/Capitul 1 - with notes]]
::::: [[Salute, Jonathan!/Capitul 2 - with notes]]
::::: [[Salute, Jonathan!/Capitul 3 - with notes]]
::::: [[Salute, Jonathan!/Capitul 4 - with notes]]
::::: [[Salute, Jonathan!/Capitul 5 - with notes]] [[User:Mithridates|Mithridates]] ([[User talk:Mithridates|discuss]] • [[Special:Contributions/Mithridates|contribs]]) 14:02, 5 October 2024 (UTC)
:::::: [[File:Yes_check.svg|{{#ifeq:|small|8|15}}px|link=|alt=]] {{#ifeq:|small|&lt;small&gt;|}}'''Done'''{{#ifeq:|small|&lt;/small&gt;|}} — [[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 23:34, 5 October 2024 (UTC)

::::::: Hi again! No luck trying to find a home for the random language translations on other auxlang wikis, can't find one that is actively maintained.
::::::: The thought struck me that maybe I could just put those ones on a sub page of my user page, would that be permitted? If not, I think I'll just stick them somewhere in GitHub and call it a day since none of the people who started the translations seem to care enough to do anything about them. I'd rather not see them outright disappear but since they aren't mine I don't care enough about them to do much more work than copy and paste them somewhere.
::::::: (I would leave the ones in languages with an ISO-639 code and Wikipedia here, of course) — [[User:Mithridates|Mithridates]] ([[User talk:Mithridates|discuss]] • [[Special:Contributions/Mithridates|contribs]]) 14:13, 9 November 2024 (UTC)

:::::::: Thank you for checking! I don't personally see an issue with moving them to your user space right now. Cheers — [[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 17:21, 9 November 2024 (UTC)

::::::::: Thanks a lot! I've started a single page where I will put them all here [[User:Mithridates/SJ]] and will proceed slowly due to lack of time and also to avoid stepping on any toes / asking you to delete too much at a time and possibly deleting the wrong content.
::::::::: For this week I have put the content for the languages Audia, Cristianès, Guosa, Lingaust, Mini, Mirad, and Monav on that page as they all have a single page of content and didn't take much time to move. Please delete those. Once they are gone I will add a note on the main page letting people know where they have gone (in addition to a thank you for their interest in the book! I do love how many people have recognized it as a good source material for teaching a language). — [[User:Mithridates|Mithridates]] ([[User talk:Mithridates|discuss]] • [[Special:Contributions/Mithridates|contribs]]) 04:09, 10 November 2024 (UTC)

: {{keep}} the translations for languages that have an article on the English Wikipedia, i.e. Guosa, Idiom Neutral, Ido, Interlingua, Lingwa de Planeta, Negerhollands, Neo, Novial, Occidental, Romanica, Solresol, Toki Pona, and Volapük.
: Translations for languages that don't have an article can be kept if they have reliable sources, which I was able to find for the following languages (if you think they are not reliable, please let me know):
:* Globasa: [https://www.languagesandnumbers.com/how-to-count-in-globasa/en/globasa/] [https://greyson.conlang.org/2020/01/29/shouting-out-globasa-and-pandunia/]
:* Mini: [https://jprogr.github.io/mini] [https://www.omniglot.com/language/phrases/mini.htm] [https://www.languagesandnumbers.com/how-to-count-in-mini/en/mini/]
: {{del}} and move to [[User:Mithridates/SJ]] the rest of the translations, i.e. Audià/Audian, Cristianés, Ekumenski, Germanisch, Interocidental, Lingaust, Lingue Simple, Masa Tang, Mirad, Monav, Monkel, Mundeze, Nordien, Novlingue, Numo, Proyo, and Scuian/Meteza. If you can find reliable sources for those languages, please let me know.
: In particular, I could not find resources for Audià/Audian and Monav after searching through 15 and 17 pages on Google, respectively. It doesn't help that [[Òla, Ionatà!|their]] [[Hai, Jon!|translations]] don't explain what those languages are and where to find resources for them. This makes contributing to those translations almost impossible until @[[User:Caro de Segeda|Caro de Segeda]] can provide resources to us. It's possible that the resources may have disappared from the Internet, or that those languages were created by Caro de Segeda him/herself. If you can find resources for Audià/Audian and Monav, please let me know.
: I'm notifying the primary contributors of the translations: @[[User:Caro de Segeda|Caro de Segeda]], @[[User:Frzzl|Frzzl]], @[[User:Greatscotteh|Greatscotteh]], @[[User:IHateNumbers234|IHateNumbers234]], @[[User:Jayeless2|Jayeless2]], @[[User:Morozof|Morozof]], @[[User:Omnihom|Omnihom]], @[[User:Omoutuazn|Omoutuazn]], @[[User:PovriNaivon|PovriNaivon]], @[[User:Sir Beluga|Sir Beluga]] and @[[User:Tyoyafud|Tyoyafud]]. — [[User:EJPPhilippines|EJPPhilippines]] ([[User talk:EJPPhilippines|discuss]] • [[Special:Contributions/EJPPhilippines|contribs]]) 09:52, 30 June 2025 (UTC)

:: Caro de Segeda said on [https://www.reddit.com/r/conlangs/comments/1lcnz9g/comment/n0sc3wx/ Reddit] that Monav was created by him/her and that he/she didn't publish any resources about it other than [[Hai, Jon!]]. With '''zero''' other resources to rely on for contributing to the translation, and the fact that Monav is in [[User:Mithridates/SJ]], [[Hai, Jon!]] should be speedy deleted. — [[User:EJPPhilippines|EJPPhilippines]] ([[User talk:EJPPhilippines|discuss]] • [[Special:Contributions/EJPPhilippines|contribs]]) 01:38, 3 July 2025 (UTC)

::: I've undone the speedy deletion as Caro de Segeda posted a [https://prexins.wordpress.com/2025/07/04/monav/ resource] for Monav. — [[User:EJPPhilippines|EJPPhilippines]] ([[User talk:EJPPhilippines|discuss]] • [[Special:Contributions/EJPPhilippines|contribs]]) 07:18, 4 July 2025 (UTC)

:::: You can delete all the ones that I have created myself, I have already moved them to other places. — [[User:Caro de Segeda|Caro de Segeda]] ([[User talk:Caro de Segeda|discuss]] • [[Special:Contributions/Caro de Segeda|contribs]]) 12:39, 5 July 2025 (UTC)

{{outdent|::::}}I don't know if this is helpful since it wouldn't apply to most of these, but [[s:mul:]] could hold some of these. — [[User:Arlo Barnes|Arlo Barnes]] ([[User talk:Arlo Barnes|discuss]] • [[Special:Contributions/Arlo Barnes|contribs]]) 09:18, 30 November 2025 (UTC)

: I don't think that would be within the scope of that project. I'm not aware of any other situation where Wikisource publishes translations of texts created on Wikimedia projects - that's usually left up to other language editions of the same project. — [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 05:34, 1 December 2025 (UTC)

:: In this situation there isn't a separate [[s:ie:]] distinct from Multilingual Wikisource (see [[meta:Wikisource#List of Wikisources]]). In fact, there are very few multilingual wikis in the Wikimedia sphere; while this project ''could'' move to a Miraheze-hosted or similar wiki farm location, I think it would be a missed opportunity. I suppose an [[Interlingue]] book could be started in [[shelf:Constructed languages]] which would have all 100 chapters as an appendix (and likewise for the other languages), but that also seems non-ideal since it requires an English-language text that doesn't currently exist to be created. [[WB:AT]] seems to describe a similar situation to this one and prescribe Wikisource as the solution, and [[WB:SOURCE]] mentions fiction as out-of-scope for Wikibooks (even as in this case, language-educational fiction). [[s:mul:Wikisource:about Wikisource]] simply speaks of source texts and doesn't mention publication requirements, so maybe that is specific to some of the monolingual editions? — [[User:Arlo Barnes|Arlo Barnes]] ([[User talk:Arlo Barnes|discuss]] • [[Special:Contributions/Arlo Barnes|contribs]]) 22:28, 5 December 2025 (UTC)

:{{keep}} 100% keep. These books are a core part of language textbooks on Wikibooks and have been for years. Not sure why this is even being debated.--[[User:Xania|Xania]] [[Image:Flag_of_Estonia.svg|15px]]  [[Image:Flag_of_Ukraine.svg|15px]] [[User talk:Xania|&lt;sup&gt;talk&lt;/sup&gt;]] 17:55, 16 May 2026 (UTC)

::With all due respect, some of the books included in this nomination (like [[Sin Chao, Jonathan!]]) are written in constructed languages which are not substantially attested anywhere else. I struggle to imagine any educational purpose for such a book. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 00:12, 17 May 2026 (UTC)

== [[International Baccalaureate]] ==

Not actually a book in and of itself; rather, it is just a compilation of links to other books —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 23:24, 18 October 2024 (UTC)
: Could this be salvaged as a shelf? [[User:Pppery|Pppery]] ([[User talk:Pppery|discuss]] • [[Special:Contributions/Pppery|contribs]]) 05:23, 27 January 2025 (UTC)
::Probably, but are the linked books even useful? IB exams change from year to year - sometimes quite dramatically - so an old exam guide is of very limited value. Many of these books were written 10-15 years ago, and some of them (like [[IB French]]) even have comments indicating that they're no longer applicable. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 02:18, 8 December 2025 (UTC)

== [[Character List for Baxter&amp;Sagart]] ==

Seems completely out of scope as an educational book; it's just a list of characters and outlinks —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 23:53, 18 October 2024 (UTC)

:Adding [[Character List for Karlgren's GSR]] and [[Character List for Schuessler's CGSR]] for the same reason —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 23:55, 18 October 2024 (UTC)

:These three books do make a package and I agree they should be considered together. However, I strongly object to deleting them. They are really extremely useful resources. I use them every week and I know that many people who do work on Old Chinese phonology do so. There are lots of books out there that are lists of characters, these are called dictionaries. For example Axel Schuessler's ABC Etymological Dictionary of Old Chinese, or Pulleyblank's Lexicon of Reconstructed Pronunciation in Early Middle Chinese, Late Middle Chinese, and Early Mandarin. I see it as entirely a good thing for reference works of this kind to be available free online rather than only in expensive books in university research libraries. If this is in violation of a Wikibooks policy, I would at least like that policy to be drawn to my attention and to have some constructive comment offered about which Wikiproject such a resource should fall under. I will also say on a personal note that I have put literally hundreds of hours of work into these projects and it would grieve me a lot to see this work simply vanish, in particular when I know that colleagues around the world use these books. --[[User:Tibetologist|Tibetologist]] ([[User talk:Tibetologist|discuss]] • [[Special:Contributions/Tibetologist|contribs]]) 07:27, 1 November 2024 (UTC)
::Hi @[[User:Tibetologist|Tibetologist]], and thank you for the feedback! Official Wikibooks policy does not permit standalone dictionaries (see [[WB:DICT]]), though I understand the argument that it is a useful resource. I am wondering if there might be a home for it at [[Wiktionary:Wiktionary:Welcome, newcomers|Wiktionary]] or [[Wikiversity:Wikiversity:SHARE|Wikiversity]]? Cheers —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 12:14, 1 November 2024 (UTC)
:::The policy says to use Wiktionary, but these books cannot be moved there. In fact they link there, you can understand me as having made an index to wiktionary, if you like, where the ORDER of the characters is extremely important, information that would be lost in Wiktionary. 
:::Wikiversity is not a project I participate in, and in any event my books here are older than it, so this option was not available for me at the relevant moment. If you are offering to move my books to Wikiversity, that is very kind of you and I will very graciously accept. [[User:Tibetologist|Tibetologist]] ([[User talk:Tibetologist|discuss]] • [[Special:Contributions/Tibetologist|contribs]]) 14:10, 1 November 2024 (UTC)
::::I have pinged over at Wikiversity Colloquium to ask about suitability and have looped you into the conversation over there. Cheers —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 18:20, 1 November 2024 (UTC)
::I concur. I'm just an undergrad who tries to learn about Sino-Tibetan historical linguistics in his free time but I've found this wikibook to be incredibly useful, and I keep it open in one tab while I watch Professor Nathan Hill's lectures that he uploads to youtube in another tab, and another tab for taking notes. In fact if I remember correctly Professor Hill actually pointed his students to this wikibook. 
::I'm not familiar with [[wikiversity:Wikiversity:SHARE|Wikiversity]] but if all the content were as accessible there as it is here then I think that could work.  [[User:ChromeBones|ChromeBones]] ([[User talk:ChromeBones|discuss]] • [[Special:Contributions/ChromeBones|contribs]]) 02:43, 9 July 2025 (UTC)
:Per [[:v:Wikiversity:Colloquium#Import_Resource_From_Wikibooks?]], I recommend copying and pasting, including attribution via the edit summary and talk page, add appropriate categories and links, and then it could be deleted locally. —[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''vf&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 22:32, 3 November 2024 (UTC)

== [[Suomen kieli käyttöön]] ==

Multiple pages in this book are written entirely in Finnish, which is out of the enWB scope. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 00:09, 19 October 2024 (UTC)

:I was going to say whether we should ask any fiwikibooks sysop to maybe see if this could be transwikied to fiwb if it's within the scope there. But [[:fi:Toiminnot:Käyttäjät/sysop]] indicates that there are only 3 sysops, and only {{u|Anr}} and {{u|Zache}} have made edits this ''year''. If they deem it to be salvageable, then transwiki + delete, otherwise straight-up delete. --[[User:SHB2000|SHB2000]] ([[User talk:SHB2000|discuss]] • [[Special:Contributions/SHB2000|contribs]]) 11:24, 14 November 2024 (UTC)
::It seems that the idea behind the book was for the pages to be bilingual, as it’s a language learning book. That’s why there are Finnish texts included intentionally even on the pages that are complete. There are similar books in dewikibooks and ruwikibooks as well. For the English version, I think the easiest way to proceed would be to clean up and adjust the page layout to fit enwikibooks better, and then translate the missing parts. By the way, if anyone wants to update the book’s name in English, it can be titled ''&quot;Using the Finnish Language&quot;'' or ''&quot;Put Finnish Language into Use&quot;'' for a direct translation.   [[User:Zache|Zache]] ([[User talk:Zache|discuss]] • [[Special:Contributions/Zache|contribs]]) 11:57, 14 November 2024 (UTC)

== [[AT&amp;T Mobility FAQ]] ==

* [[AT&amp;T Mobility FAQ]]
* [[AT&amp;T Mobility FAQ/MEdia Net Configuration]]
* [[AT&amp;T Mobility FAQ/Data Connect Configuration]]
An ''extremely'' outdated FAQ on AT&amp;T's cell phone services. Most of this document was written 20+ years ago as a Usenet FAQ; very little of it is accurate or useful anymore (particularly the two subpages, which have to do with obsolete configurations for &quot;tethering&quot; a computer to a cell phone). No objection if someone wants to update it, but there's clearly been no appetite to do that. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 22:20, 30 December 2024 (UTC)

:I'm wondering if it might make sense for us to develop some kind of policy on archiving books here. There are many like this one that have a good deal of content but are extremely out of date and just not useful as originally intended. ——[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 22:34, 30 December 2024 (UTC)
::@[[User:Kittycataclysm|Kittycataclysm]]: See the newly developed [[Wikibooks:Outdated books]]. [[User:JJPMaster|JJP]]&lt;sub&gt;[[User talk:JJPMaster|Mas]]&lt;sub&gt;[[Special:Contributions/JJPMaster|ter]]&lt;/sub&gt;&lt;/sub&gt; ([[wikt:she|she]]/[[wikt:they|they]]) 00:16, 31 December 2024 (UTC)
:::Ooh, thanks - something like that seems like it could be an appropriate way to handle this book. A lot of the other outdated books I've tagged have been so incomplete that they wouldn't have been particularly useful even as historical references; this one might at least have some interest.
:::Any chance we can get a separate namespace (maybe &quot;Archive:&quot;) set up for archived book content? That'd make it possible to do things like exclude them from on-site search by default. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 21:07, 31 December 2024 (UTC)
::::I think this might be a more extended discussion, so I'll bump it over to the [[Wikibooks talk:Outdated books|talk page of the draft policy]]! —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 21:54, 31 December 2024 (UTC)

== Algebra/Chapter 10/Symmetric Polynomials ==

I personally believe that [[Algebra/Chapter 10/Symmetric Polynomials|this]], and all of the sections should be deleted for the fact that this goes WAY beyond the scope of what was intended for the Chapter (Algebra II level polynomials). [[User:GoreyCat|GoreyCat]] ([[User talk:GoreyCat|discuss]] • [[Special:Contributions/GoreyCat|contribs]]) 15:07, 6 February 2025 (UTC)

:'''Split''': Deletion here is not the best solution (see [[w:WP:ATD]]). Instead, this page and its subpages should be moved to another book, most likely [[Abstract Algebra]]. [[User:JJPMaster|JJP]]&lt;sub&gt;[[User talk:JJPMaster|Mas]]&lt;sub&gt;[[Special:Contributions/JJPMaster|ter]]&lt;/sub&gt;&lt;/sub&gt; ([[wikt:she|she]]/[[wikt:they|they]]) 17:35, 6 February 2025 (UTC)
:{{keep}} since there is a good amount of content. If [[Abstract Algebra]] is appropriate, it seems like a fine idea to move there. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 22:59, 7 February 2025 (UTC)
::Eh, yeah, I supposed moving it is better. I just don't think it's suitable for where it appears. [[User:GoreyCat|GoreyCat]] ([[User talk:GoreyCat|discuss]] • [[Special:Contributions/GoreyCat|contribs]]) 01:40, 8 February 2025 (UTC)
== [[Puredyne]] ==

Development of Puredyne Linux was discontinued in 2012, and the software no longer appears to be available for download anywhere. (An archive of the web site is still up - with a bunch of embedded spam links - but the download links are all dead.) Is this a suitable candidate for archival (cf. [[Wikibooks:Outdated books]]), or should it just be deleted? [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 04:35, 5 March 2025 (UTC)

:I'd just archive stuff like this. Looks like a decent bit of work went into it, and you never know when someone might need to use Puredyne for some obscure project. I'd be willing to bet mirrors exist of it somewhere, or someone has it on a drive. If you want to find some stuff worth deleting, comb through [[:Category:Allbooks categories]]. [[User:MediaKyle|MediaKyle]] ([[User talk:MediaKyle|discuss]] • [[Special:Contributions/MediaKyle|contribs]]) 11:30, 5 March 2025 (UTC)

== [[Template:Qr-twwp]] ==
This isn't exactly a request to delete the template, but rather to merge it with {{tlx|Copypaste}}. The {{tlx|Qr-twwp}} template serves the same purpose as {{tlx|Copypaste}}, but without the seven-day period after which the page is deleted. This leads to confusion, as well as a perpetually full [[:Category:Queried pages]]. [[User:JJPMaster|JJP]]&lt;sub&gt;[[User talk:JJPMaster|Mas]]&lt;sub&gt;[[Special:Contributions/JJPMaster|ter]]&lt;/sub&gt;&lt;/sub&gt; ([[wikt:she|she]]/[[wikt:they|they]]) 17:37, 30 March 2025 (UTC)

== [[Ghouls of the Miskatonic]] ==

I don't think that a plot summary of a book is in-scope here. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 18:43, 20 August 2025 (UTC)

:{{vd}} - at least, not a summary of ''this'' book. A summary and/or study guide to a notable work of literature might be in scope, but this is certainly not one. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 21:23, 25 August 2025 (UTC)
::Hi. I am the creator of the pages of this book. If I understand correctly, it has to be a summary of a notable work of literature? So what exactly is defined as such? I only started this as I thought it would be fun, interesting and encouraging to others who read the Arkham Horror novels, and I thought it was permitted as I've seen other summaries of books on wikibooks. [[User:Dayne90|Dayne90]] ([[User talk:Dayne90|discuss]] • [[Special:Contributions/Dayne90|contribs]]) 13:27, 26 August 2025 (UTC)
:::Your problem is it is just the plot... it needs to include an educational textual analysis to be in scope [[User:MarcGarver|MarcGarver]] ([[User talk:MarcGarver|discuss]] • [[Special:Contributions/MarcGarver|contribs]]) 12:47, 28 August 2025 (UTC)
::::And ideally it'd be a text which has ''already'' been the subject of literary analysis, such that the analysis on Wikibooks isn't original research. A notable work of literature like ''Frankenstein'' or ''Moby-Dick'' would easily meet that requirement; a tie-in novel for a tabletop RPG probably does not. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 22:08, 29 August 2025 (UTC)

== [[Objective Projection: Why the Brain Never Forgets Some Stories]] ==

Undisclosed AI-generated content. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 02:13, 9 May 2026 (UTC)

:&lt;nowiki&gt;'''Keep'''&lt;/nowiki&gt; — Comment from page author/subject expert.
:I am Levent Bulut, the originator of the &lt;nowiki&gt;''&lt;/nowiki&gt;Objective Projection&lt;nowiki&gt;''&lt;/nowiki&gt; methodology described in this book (ORCID: 0009-0007-7500-2261, Wikidata: Q138048287). I want to address the AI-generated content concern directly and transparently.
:&lt;nowiki&gt;'''&lt;/nowiki&gt;On the content itself:&lt;nowiki&gt;'''&lt;/nowiki&gt; The methodology, theoretical framework (the six-variable operator E(r) = projS(M, T, V, Δ, Ω, Ng), the Six Golden Rules, the Six-Layer Framework), and all original arguments are my own intellectual work, developed and published independently. This is documented through:
:* 26 DOI-registered academic publications on Zenodo (search: &quot;Levent Bulut Objective Projection&quot;)
:* A peer-reviewed submission currently under review at &lt;nowiki&gt;''&lt;/nowiki&gt;Digital Humanities Quarterly&lt;nowiki&gt;''&lt;/nowiki&gt;
:* Parallel Turkish-language Wikibook and Wikiversity pages on the same methodology
:* An open-source SFT dataset on Hugging Face (leventbulut/objective-projection)
:&lt;nowiki&gt;'''&lt;/nowiki&gt;On AI assistance:&lt;nowiki&gt;'''&lt;/nowiki&gt; I used AI tools (Claude) for English translation polish and copy-editing from my Turkish source materials — the same way a non-native English-speaking academic would use a human translator or editor. The &lt;nowiki&gt;''&lt;/nowiki&gt;ideas, structure, terminology, citations, and arguments&lt;nowiki&gt;''&lt;/nowiki&gt; are entirely my own and pre-date the Wikibooks version, traceable through Zenodo DOI timestamps starting in 2025.
:&lt;nowiki&gt;'''&lt;/nowiki&gt;Proposed remedy instead of deletion:&lt;nowiki&gt;'''&lt;/nowiki&gt; I am happy to:
:# Add a clear AI-assistance disclosure to the book's preface, per Wikibooks transparency norms
:# Add inline citations to the underlying DOI-registered publications for every major claim
:# Link to the parallel Turkish version and academic record
:This would address the &lt;nowiki&gt;''&lt;/nowiki&gt;undisclosed&lt;nowiki&gt;''&lt;/nowiki&gt; part of the concern (which is the actionable policy issue) while preserving content that is original academic work by an identifiable author with a published track record. Deletion of original scholarship because translation assistance was used would set a concerning precedent for non-native English contributors.
:&lt;nowiki&gt;I request a few days to add the disclosure and citations before any deletion action. ~~~~&lt;/nowiki&gt; [[Special:Contributions/&amp;#126;2026-28847-60|&amp;#126;2026-28847-60]] ([[User talk:&amp;#126;2026-28847-60|talk]]) 18:46, 13 May 2026 (UTC)
::Administrative assistance needed: Automated filters blocking structural improvements and disclosures
::'''Request for Help''' — I am Levent Bulut, the author of this book. I have already provided my AI disclosure and academic credentials (ORCID, DOI list) here in this discussion.
::I am trying to update the book to comply with Wikibooks standards by:
::Adding a formal '''AI assistance disclosure''' at the top of the page.
::Restructuring the content into an '''instructional textbook format''' (adding Learning Objectives).
::Converting plain text formulas into '''LaTeX''' ( format).
::Updating references to include full academic '''DOI''' records.
::However, the automated filter is blocking all my attempts:
::If I try to replace the content with the improved version, it triggers the '''&quot;large amount of content removal&quot;''' filter.
::If I try to add specific academic links, it triggers the '''&quot;automated link/spam&quot;''' filter.
::I am essentially trapped by the filters while trying to improve the book and follow transparency norms. Could an administrator please either whitelist my account or manually apply the improved version of the text? I am ready to provide the full MediaWiki code here if requested. My intent is purely constructive and academic. [[Special:Contributions/&amp;#126;2026-28847-60|&amp;#126;2026-28847-60]] ([[User talk:&amp;#126;2026-28847-60|talk]]) 19:15, 13 May 2026 (UTC)
::: Hi, @[[User:~2026-28847-60|~2026-28847-60]]. Your account was incorrectly locked by a steward. It is now currently unlocked. [[User:Codename Noreste|&lt;span style=&quot;color:#0024FF&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 17:44, 15 May 2026 (UTC)
:::: Pinging @[[User:Projection Architect|Projection Architect]], who was previously LeventBulut. [[User:Codename Noreste|&lt;span style=&quot;color:#0024FF&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 15:51, 4 July 2026 (UTC)
::Please review [[Wikibooks:Artificial intelligence]]. It states unequivocally that {{tq|LLMs may not be used to generate or summarize material and ideas at Wikibooks}}, and that {{tq|translations made by LLMs are not allowed on Wikibooks}}. The fact that you did not disclose your usage of AI is part of the problem, but disclosing it does not make it allowable either.
::More broadly, based on what you've said above, the content of this book is a reflection of your personal theories on writing. This is essentially [[Wikibooks:Original research]] and is not permitted. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 22:36, 13 May 2026 (UTC)

== [[Suicide]] ==

I realize this book has been nominated for deletion before ([[Wikibooks:Requests for deletion/Suicide|1]], [[Wikibooks:Requests for deletion/Suicide (2)|2]], [[Wikibooks:Requests for deletion/Suicide/Suffocation|3]]), but it's been over ten years since the last nomination. The project's position on what material is in its educational scope has shifted, as have some of the facts on the ground.

* The chartered purpose of Wikibooks is to produce &quot;open-content textbooks&quot; (cf. [[Wikibooks:What is Wikibooks?]]) which are suitable for use in an instructional environment. Providing educational information about suicide in the context of psychiatry could certainly be in scope, as psychiatry is an educational topic; however, instructional material on how to commit suicide is not an educational topic, and should not be considered in scope.
* This book is, and has always been, primarily intended as an instructional work guiding users on how to commit suicide. It provides effectively no meaningful analytical content ''about'' suicide as a topic. Most of the original content in the book was imported from an early-2000s wiki associated with the &lt;code&gt;alt.suicide.holiday&lt;/code&gt; Usenet group, the &quot;ASH wiki&quot;, which was specifically and unequivocally dedicated to describing and recommending methods by which readers could commit suicide, and this has carried through to the current version of the book.
* Most of the content in the book was removed in 2020 (by redirecting it to the book's main page, e.g. [[Special:Diff/3660495]]) over concerns that it was created by a WMF-banned user ([[User:Leucosticte]]), and because it was likely in violation of the ASH wiki's (unclear) copyright. These changes removed most of the content of the book; much of what remains is image gallery pages like [[Suicide/Blades]] which have no educational value.

Suicide is a sensitive topic; if it is covered by a textbook, it should be covered tastefully and with an aim to educate. This book is largely the opposite of that. Having it here is doing more harm than good.

If this book is deleted, the following related pages should be deleted as well:
* [[Template:Suicide methods]]
* [[Template:Infobox suicide method]] (currently unused)
* [[User:Leucosticte/About ASH]] - from the ASH wiki, as mentioned above
* [[User:Leucosticte/Frequently Asked Questions]] - also from the ASH wiki
[[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 22:41, 21 July 2026 (UTC)
: {{keep|weak keep}} a)&amp;nbsp;Age is no argument. There are many stale underdeveloped books I would rather delete than keeping around. b)&amp;nbsp;The book’s topic is exceptionally difficult to write about. ''This'' impedes collaborative authoring. c)&amp;nbsp;The book does not really explain ''how'' to commit suicide (like a step‐by‐step guide), neither is it the book’s learning objective. d)&amp;nbsp;Even if ''you construed'' the chapter summarizing various suicide methods ''as instructions'', instructional material on how to commit suicide ''is'' an educational topic. In most ''present‐day societies'' it is not ''ethical'' to teach students how to commit suicide, though. e)&amp;nbsp;Therefore the correct path is to first alter the [[WB:WIW#Wikibooks includes instructional texts|project scope]] to censor books on ethical grounds ''and then'' nominate the book for censorship. ‑‑[[User:Kai Burghardt|Kai Burghardt]] ([[User talk:Kai Burghardt|discuss]] • [[Special:Contributions/Kai Burghardt|contribs]]) 04:50, 28 July 2026 (UTC)
::Re. c: most of the explicit directions were edited out in 2020, as noted in my nomination, but are still visible in page history. For a couple of explicit examples, see e.g. [[Special:Permalink/3318613]] or [[Special:Permalink/3654645]]. Providing specific instructions was the original intent of this book, and it has never escaped that legacy. If someone were interested in writing a book ''about'' the phenomenon of suicide, they would be better off starting afresh. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 05:26, 28 July 2026 (UTC)
*'''Delete all'''. ―[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''&lt;span style=&quot;color:black&quot;&gt;v&lt;/span&gt;f&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 16:17, 28 July 2026 (UTC)
* '''Delete all''' per the nomination above. [[User:Codename Noreste|&lt;span style=&quot;color: blue&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 02:17, 30 July 2026 (UTC)

== Unused infoboxes ==

The following infobox templates are all unused (outside of user sandboxes, in some cases) and should probably be deleted. I've edited/removed a few instances of some of these templates which were being used in nonproductive ways (e.g. infoboxes which were only being used to display an image).

* [[:Template:Infobox Probability Distribution]]
* [[:Template:Infobox church]]
* [[:Template:Infobox color]]
* [[:Template:Infobox company]]
* [[:Template:Infobox historical event]]
* [[:Template:Infobox officeholder]]
* [[:Template:Infobox song]]
[[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 22:44, 21 July 2026 (UTC)

:'''Delete all''' ―[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''&lt;span style=&quot;color:black&quot;&gt;v&lt;/span&gt;f&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 16:18, 28 July 2026 (UTC)

== [[User:PETER A. SAUL/You Become What You Think: Transform Your Life]] ==
Overall reads like a violation of [[WB:SOAP]]. Mass addition of pages. Bold claims with no reputable sources/support. See e.g. [[Peter A. Saul: Personal Development and Mindset Anthology/You Become What You Think/Chapter 9|here]]. Markdown errors that suggest LLM use (e.g. [[Peter A. Saul: Personal Development and Mindset Anthology/You Become What You Think/Chapter 16|here]], [[Peter A. Saul: Personal Development and Mindset Anthology/You Become What You Think/Chapter 17|here]], etc. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 14:21, 5 August 2026 (UTC)

:I'll also note a significant amount of self-promo. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 14:32, 5 August 2026 (UTC)
:'''Speedy delete''' Obviously inappropriate. ―[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''&lt;span style=&quot;color:black&quot;&gt;v&lt;/span&gt;f&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 17:17, 5 August 2026 (UTC)
::{{done}}. I was on the fence for speedy, but since another admin agrees, I went ahead and deleted. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 18:38, 5 August 2026 (UTC)

== [[User:PETER A. SAUL/Why 95 Percent of Your Life Is a Lie: How to Control Your Mind]] ==
Same reasons as RFD for other pages by this editor. Violation of [[WB:SOAP]], no support for extreme claims, potential LLM use, self-promo. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 14:28, 5 August 2026 (UTC)

:'''Speedy delete''' Obviously inappropriate. ―[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''&lt;span style=&quot;color:black&quot;&gt;v&lt;/span&gt;f&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 17:17, 5 August 2026 (UTC)
::{{done}}. As with other contributions. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 18:38, 5 August 2026 (UTC)</text>
      <sha1>5yo0vl06xwugxmqu5lz1yi9o019dvj4</sha1>
    </revision>
  </page>
  <page>
    <title>Spanish/Verbs List</title>
    <ns>0</ns>
    <id>3748</id>
    <revision>
      <id>4657119</id>
      <parentid>4639324</parentid>
      <timestamp>2026-08-11T00:44:27Z</timestamp>
      <contributor>
        <username>~2026-44012-50</username>
        <id>3620603</id>
      </contributor>
      <comment>I added a verb that I learnt at school to the 'C' category, the word is cebar which means to feed or to fatten animals such as lifestock.</comment>
      <origin>4657119</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="12900" sha1="in89798fj4h9pb551pzqhvg4k2a4cz4" xml:space="preserve">__NOTOC__
[[Spanish/Verbs]]
----
{{Spanish Verbs}}
==A==
*[[wiktionary:abrazar|Abrazar]] (to hug)
*[[wiktionary:abrir|Abrir]] (to open) abro abras abra
*[[wiktionary:acabar|Acabar]] (to finish)
*[[wiktionary:acabar|Acabar]] de (to have just)
*[[wiktionary:acordar|Acordar]] (to agree upon)
*[[wiktionary:acompañar|Acompañar]] (to accompany)
*[[wiktionary:acostarse|Acostarse]] (to go to bed)
*[[wiktionary:afeitarse|Afeitarse]] (to shave oneself) ''ref.''
*[[wiktionary:ahorrar|Ahorrar]] (to save money)
*[[wiktionary:almorzar|Almorzar]] (to eat lunch)
*[[wiktionary:alquilar|Alquilar]] (to rent)
*[[wiktionary:amar|Amar]] (to love) - typical 1st conjugation verb
*[[wiktionary:añadir|Añadir]] (to add)
*[[wiktionary:andar|Andar]] (to walk, to go, to ride)
*[[wiktionary:aparecer|Aparecer]] (to appear)
*[[wiktionary:apagar|Apagar]] (to turn off)
*[[wiktionary:aplanar|Aplanar]] (to throw out)
*[[wiktionary:aplastar|Aplastar]] (to flatten)
*[[wiktionary:aprender|Aprender]] (to learn)
*[[wiktionary:aprobar|Aprobar]] (to approve, to pass)
*[[wiktionary:arrastrarse|Arrastrarse]] (to crawl, to drag oneself) ''ref.''
*[[wiktionary:arreglar|Arreglar]] (to fix)
*[[wiktionary:atacar|Atacar]] (to attack)
*[[wiktionary:asistir|Asistir]] (to attend)
*[[wiktionary:asustar|Asustar]] (to frighten)
*[[wiktionary:aumentar|Aumentar]] (to increase)
*[[wiktionary:ayudar|Ayudar]] (to help)

==B==
*[[Wiktionary:Bailar|Bailar]] (to dance)
*[[Wiktionary:Bañarse|Bañarse]] (to bathe) ''ref.''
*[[Wiktionary:Barrer|Barrer]] (to sweep)
*[[Wiktionary:Batir|Batir]] (to whisk)
*[[Wiktionary:Beber|Beber]] (to drink)
*[[Wiktionary:Besar|Besar]] (to kiss)
*[[Wiktionary:Borrar|Borrar]] (to erase)
*[[Wiktionary:Bromear|Bromear]] (to joke)
*[[Wiktionary:Bucear|Bucear]] (to dive)
*[[Wiktionary:Burlarse|Burlarse]] (to make fun of) ''ref.''
*[[Wiktionary:Buscar|Buscar]] (to look for)

==C==
*[[Wiktionary:Calentar|Calentar]] (to heat)
*[[Wiktionary:Calificar|Calificar]] (to grade)
*[[Wiktionary:Caminar|Caminar]] (to walk)
*[[Wiktionary:Cansarse|Cansarse]] (to tire) ''ref.''
*[[Wiktionary:Cantar|Cantar]] (to sing)
*[[Wiktionary:Casarse|Casarse]] (to marry) ''ref.''
*[[Wiktionary:Cazar|Cazar]] (to hunt)
*Cebar (to feed, to fatten) animals
*[[Wiktionary:Celebrar|Celebrar]] (to celebrate)
*[[Wiktionary:Cenar|Cenar]] (to dine, to have supper)
*[[Wiktionary:Cepillar|Cepillar(se)]] (to brush) can be ''ref.''
*[[Wiktionary:Cerrar|Cerrar]] (to close)
*[[Wiktionary:Charlar|Charlar]] (to chat)
*[[Wiktionary:Chupar|Chupar]] (to suck)
*[[Wiktionary:Cocinar|Cocinar]] (to cook)
*[[Wiktionary:Coger|Coger]] (to catch)
*[[Wiktionary:Comer|Comer]] (to eat, esp. to eat lunch)
*[[Wiktionary:Comprar|Comprar]] (to purchase, to buy)
*[[Wiktionary:Comprender|Comprender]] (to comprehend, to understand)
*[[Wiktionary:Conducir|Conducir]] (to drive)
*[[Wiktionary:Conocer|Conocer]] (to know, to meet)
*[[Wiktionary:Contar|Contar]] (to relate)
*[[Wiktionary:Contestar|Contestar]] (to answer, to reply)
*[[Wiktionary:Correr|Correr]] (to run)
*[[Wiktionary:Cortar|Cortar]] (to cut)
*[[Wiktionary:Costar|Costar]] (to cost) (ue)
*[[Wiktionary:Crear|Crear]] (to create)
*[[Wiktionary:Creer|Creer]] (to believe)
*[[Wiktionary:Cuajar|Cuajar]] (to curdle)
*[[Wiktionary:Cubrir|Cubrir]] (to cover)
*[[Wiktionary:Cumplir|Cumplir]] (to fulfill)

==D==
*[[Wiktionary:Dar|Dar]] (to give)
*[[Wiktionary:Deber|Deber]] (to owe, should)
*[[Wiktionary:Decidir|Decidir]] (to decide)
*[[Wiktionary:Decir|Decir]] (to say, to tell)
*[[Wiktionary:Dejar|Dejar]] (to leave)
*[[Wiktionary:Desayunar|Desayunar]] (to eat breakfast)
*[[Wiktionary:Descansar|Descansar]] (to rest)
*[[Wiktionary:Desear|Desear]] (to desire, to wish)
*[[Wiktionary:Deshacer|Deshacer]] (to undo)
*[[Wiktionary:Despedir|Despedir]] (to fire)
*[[Wiktionary:Despedirse|Despedirse]] (to say goodbye)
*[[Wiktionary:Despertarse|Despertarse]] (to wake up) - Irregular: e -&gt; ie
*[[Wiktionary:Destruir|Destruir]] (to destroy)
*[[Wiktionary:Detener|Detener]] (to stop)
*[[Wiktionary:Dirigir|Dirigir]] (to lead, to guide)
*[[Wiktionary:Disculparse|Disculparse]] (to excuse oneself)
*[[Wiktionary:Discutir|Discutir]] (to argue)
*[[Wiktionary:Distinguir|Distinguir]] (to distinguish)
*[[Wiktionary:Divertirse|Divertirse]] (to have fun) - Irregular: e -&gt; ie
*[[Wiktionary:Doler|Doler]] (to hurt)
*[[Wiktionary:Dormir|Dormir]] (to sleep, go to sleep) - Irregular: o &amp;rarr; ue
*[[Wiktionary:Duchar|Duchar(se)]] (to shower (oneself)) - Can be ''ref.''

==E==
*[[Wiktionary:Echar|Echar]] (to deal (cards))
*[[Wiktionary:Elegir|Elegir]] (to choose, to elect)
*[[Wiktionary:Empeorar|Empeorar]] (to worsen)
*[[Wiktionary:Empezar|Empezar]] (to begin)
*[[Wiktionary:Empujar|Empujar]] (to push)
*[[Wiktionary:Enamorarse|Enamorarse]] (to fall in love)
*[[Wiktionary:Encantar|Encantar]] (to be delighted about) - ''gustar-type verb''
*[[Wiktionary:Encender|Encender]] (to light)
*[[Wiktionary:Enfermar|Enfermar]] (to get sick)
*[[Wiktionary:Enojarse|Enojarse]] (to be angry)
*[[Wiktionary:Enseñar|Enseñar]] (to teach)
*[[Wiktionary:Entender|Entender]] (to understand)
*[[Wiktionary:Entrar|Entrar]] (to enter)
*[[Wiktionary:Escuchar|Escuchar]] (to listen)
*[[Wiktionary:Escribir|Escribir]] (to write)
*[[Wiktionary:Esperar|Esperar]] (to wait, to hope)
*[[Wiktionary:Esquiar|Esquiar]] (to ski)
*[[Wiktionary:Estar|Estar]] (to be)
*[[Wiktionary:Estudiar|Estudiar]] (to study)
*[[Wiktionary:Exportar|Exportar]] (to export)

==F==
*[[Wiktionary:Fastidiar|Fastidiar]] (to annoy, to tease)
*[[Wiktionary:Felicitar|Felicitar]] (to congratulate)
*[[Wiktionary:Fingir|Fingir]] (to pretend, to fake)
*[[Wiktionary:Firmar|Firmar]] (to sign)
*[[Wiktionary:Flipar|Flipar]] (to be crazy about) - ''gustar-type verb''
*[[Wiktionary:Freir|Freir]] (to fry)
*[[Wiktionary:Fusilar|Fusilar]] (to execute by firing squad)

==G==
*[[Wiktionary:Ganar|Ganar]] (to win, to earn)
*[[Wiktionary:Gastar|Gastar]] (to spend, to use up)
*[[Wiktionary:Gritar|Gritar]] (to shout)
*[[Wiktionary:Guiar|Guiar]] (to lead, to guide)
*[[Wiktionary:Gustar|Gustar]] (to be pleasing) ''-equivalent to the english &quot;to like&quot;''

==H==
*[[../Haber/]] (to have [helper verb])
*[[Wiktionary:Hablar|Hablar]] (to talk)
*[[Wiktionary:Hacer|Hacer]] (to make, to do)
*[[Wiktionary:Hacer|Hacer calor]] (to be hot)
*[[Wiktionary:Hallar|Hallar]] (to find)
*[[Wiktionary:Helar|Helar]] (to freeze)
*[[Wiktionary:Herir|Herir]] (to injure)
*[[Wiktionary:Hinchar|Hinchar]] (to anger)
*[[Wiktionary:Huir|Huir]] (to flee)
*[[Wiktionary:Hundir|Hundir]] (to sink)

== I ==
*[[Wiktionary:Insultar|Insultar]] (to insult)
*[[../Ir/]] (to go)
*[[Wiktionary:Irse|Irse]] (to go [away]) reflexive verb
*[[Wiktionary:Invitar|Invitar]] (to invite)
*[[Wiktionary:Injerir|Injerir]] (to inject, insert)

==J==
*[[Wiktionary:Jalar|Jalar]] (to pull)
*[[Wiktionary:Jugar|Jugar]] (to play)
*[[Wiktionary:Jurar|Jurar]] (to swear)
*[[Wiktionary:Juzgar|Juzgar]] (to judge)

==L==
*[[Wiktionary:Lastimar|Lastimar]] (to hurt emotionally)
*[[Wiktionary:Lavar|Lavar]] (to wash)
*[[Wiktionary:Leer|Leer]] (to read)
*[[Wiktionary:Llegar a ser|Llegar a ser]] (to become)
*[[Wiktionary:Levantar|Levantar]] (to raise)
*[[Wiktionary:Limpiar|Limpiar]] (to clean)
*[[Wiktionary:Llegar|Llegar]] (to arrive)
*[[Wiktionary:Llevar|Llevar]] (to bring, to carry)
*[[Wiktionary:Llorar|Llorar]] (to cry)
*[[../Llover/]] (to rain)
*[[Wiktionary:Lograr|Lograr]] (to accomplish)
*[[Wiktionary:Luchar|Luchar]] (to fight, to struggle)

==M==
*[[Wiktionary:Manejar|Manejar]] (to drive)
*[[Wiktionary:Matar|Matar]] (to kill)
*[[Wiktionary:Mejorar|Mejorar]] (to get better)
*[[Wiktionary:Meter|Meter]] (to place inside)
*[[Wiktionary:Mirar|Mirar]] (to look)
*[[Wiktionary:Mojar|Mojar]] (to wet)
*[[Wiktionary:Molestar|Molestar]] (to annoy, to bother)
*[[Wiktionary:Morir|Morir]] (to die)

==N==
*[[Wiktionary:Nacer|Nacer]] (to be born)
*[[Wiktionary:Nadar|Nadar]] (to swim)
*[[Wiktionary:Navegar|Navegar]] (to navigate)
*[[Wiktionary:Necesitar|Necesitar]] (to need)
*[[Wiktionary:Negar|Negar]] (to deny)
*[[Wiktionary:Nevar|Nevar]] (to snow)

==O==
*[[Wiktionary:Obtener|Obtener]] (to get, to obtain)
*[[Wiktionary:Odiar|Odiar]] (to hate)
*[[Wiktionary:Ofrecer|Ofrecer]] (to offer)
*[[Wiktionary:Oír|Oír]] (to hear)
*[[Wiktionary:Oler|Oler]] (to smell) - Irregular: o -&gt; hue
*[[Wiktionary:Olvidar|Olvidar]] (to forget)
*[[Wiktionary:Operar|Operar]] (to operate)
*[[Wiktionary:Orar|Orar]] (to pray)

==P==
*[[Wiktionary:Pagar|Pagar]] (to pay)
*[[Wiktionary:Parecer|Parecer]] (to appear)
*[[Wiktionary:Parecer|Parecer a]] (to resemble)
*[[Wiktionary:Participar|Participar]] (to participate)
*[[Wiktionary:Partir|Partir]] (to cut, to leave) - typical 3rd conjugation verb
*[[Wiktionary:Pasar|Pasar]] (to pass, to happen)
*[[Wiktionary:Pasear|Pasear]] (to ride, to stroll)
*[[Wiktionary:Pedir|Pedir]] (to ask for) - Irregular
*[[Wiktionary:Peinarse|Peinarse]] (to comb oneself) ''ref.''
*[[Wiktionary:Pelear|Pelear]] (to fight)
*[[Wiktionary:Pensar|Pensar]] (to think)
*[[Wiktionary:Perder|Perder]] (to lose)
*[[Wiktionary:Perseguir|Perseguir]] (to chase)
*[[Wiktionary:Pintar|Pintar]] (to paint)
*[[Wiktionary:Pisar|Pisar]] (to step on)
*[[Wiktionary:Planchar|Planchar]] (to iron)
*[[Wiktionary:Platicar|Platicar]] (to chat)
*[[Wiktionary:Poder|Poder]] (to be able)
*[[Wiktionary:Poner|Poner]] (to put, to place, to set)Note: The Yo form of poner is &quot;pongo&quot;
*[[Wiktionary:Practicar|Practicar]] (to practice)
*[[Wiktionary:Preguntar|Preguntar]] (to ask)
*[[Wiktionary:Preparar|Preparar]] (to prepare)
*[[Wiktionary:Prestar|Prestar]] (to lend)

==Q==
*[[Wiktionary:Quedarse|Quedarse]] (to stay) ''ref.''
*[[Wiktionary:Quejarse|Quejarse]] (to complain, to grumble) ''ref.''
*[[Wiktionary:Quemar|Quemar]] (to burn)
*[[Wiktionary:Querer|Querer]] (to want, to like) - Irregular: e -&gt; ie
*[[Wiktionary:Querer|Querer decir]] (to mean, to signify)
*[[Wiktionary:Quitar|Quitar]] (to take away)

==R==
*[[Wiktionary:Rasurarse|Rasurarse]] (to shave oneself)
*[[Wiktionary:Recibir|Recibir]] (to receive)
*[[Wiktionary:Reciclar|Reciclar]] (to recycle)
*[[Wiktionary:Recordar|Recordar]] (to remember)
*[[Wiktionary:Recoger|Recoger]] (to gather, to pick up)
*[[wiktionary:Regalar|Regalar]] (to give [as a gift])
*[[Wiktionary:Regresar|Regresar]] (to return)
*[[Wiktionary:Reír|Reír]] (to laugh)
*[[Wiktionary:Repartir|Repartir]] (to distribute)
*[[Wiktionary:Resistir|Resistir]] (to bear)
*[[Wiktionary:Rogar|Rogar]] (to pray, to beg)
*[[Wiktionary:Romper|Romper]] (to rip, to break)

==S==
*[[Wiktionary:Saber|Saber]] (to know)
*[[Wiktionary:Sacar|Sacar]] (to take out)
*[[Wiktionary:Salir|Salir]] (to leave, to go out)
*[[Wiktionary:Saludar|Saludar]] (to greet)
*[[Wiktionary:Secar|Secar]] (to dry)
*[[Wiktionary:Seguir|Seguir]] (to follow)
*[[Wiktionary:Sentarse|Sentarse]] (to sit)
*[[Wiktionary:Sentir|Sentir]] (to feel)
*[[Wiktionary:Ser|Ser]] (to be)
*[[Wiktionary:Significar|Significar]] (to mean, to signify)
*[[Wiktionary:Sonar|Sonar]] (to ring)
*[[Wiktionary:Sonreír|Sonreír]] (to smile)
*[[Wiktionary:Sonrojarse|Sonrojarse]] (to blush)
*[[Wiktionary:Soñar|Soñar]] (to dream)
*[[Wiktionary:Soportar|Soportar]] (to bear)
*[[Wiktionary:Subir|Subir]] (to go up, to get on)

==T==
*[[Wiktionary:Temer|Temer]] (to fear) - typical 2nd conjugation verb
*[[Wiktionary:Tener|Tener]] (to have, to own)e --&gt; ie except for yo, which is &quot;tengo&quot;
*[[Wiktionary:Tener|Tener razón]] (to be right)
*[[Wiktionary:Tentar|Tentar]] (to touch)
*[[Wiktionary:Terminar|Terminar]] (to finish, to end)
*[[Wiktionary:Tirar|Tirar]] (to throw, to shoot)
*[[Wiktionary:Tocar|Tocar]] (to touch, to play an instrument)
*[[Wiktionary:Tomar|Tomar]] (to take, to drink)
*[[Wiktionary:Trabajar|Trabajar]] (to work)
*[[Wiktionary:Traducir|Traducir]] (to translate)
*[[Wiktionary:Tragar|Tragar(se)]] (to swallow)
*[[Wiktionary:Traer|Traer]] (to bring)

==U==
*[[Wiktionary:Usar|Usar]] (to use)
*[[Wiktionary:utilizar|Utilizar]] (to use)

==V==
*[[Wiktionary:Vencer|Vencer]] (to conquer, to defeat)
*[[Wiktionary:Vender|Vender]] (to sell)
*[[Wiktionary:Venir|Venir]] (to come)
*[[Wiktionary:Ver|Ver]] (to see)
*[[Wiktionary:Viajar|Viajar]] (to travel)
*[[Wiktionary:Visitar|Visitar]] (to visit)
*[[Wiktionary:Vivir|Vivir]] (to live)
*[[Wiktionary:Volver|Volver]] (to return)

==Y==
*[[Wiktionary:yacer|Yacer]] (to lie)

==Z==
*[[Wiktionary:Zafar|Zafar]] (to untie)
*[[Wiktionary:Zanjar|Zanjar]] (to resolve)

{{Spanish Verbs}}
----
[[Spanish/Verbs]]

==External links==
*[http://www.amazon.com/exec/obidos/ASIN/0658014870/qid=1120440532/sr=2-1/ref=pd_bbs_b_2_1/103-1437568-3269459 The Big Red Book of Spanish Verbs]
*[http://www.amazon.com/exec/obidos/tg/detail/-/0764124285/qid=1120440612/sr=8-1/ref=pd_bbs_ur_1/103-1437568-3269459?v=glance&amp;s=books&amp;n=507846 501 Spanish Verbs]
*[http://www.helloworld.com.es/english/quick%20reference/verbs/spanishverblist.htm Fully Conjugated Spanish VerbList] They call it LazyMood. Good online reference.

{{BookCat}}</text>
      <sha1>in89798fj4h9pb551pzqhvg4k2a4cz4</sha1>
    </revision>
  </page>
  <page>
    <title>Chess Opening Theory/1. e4/1...d5</title>
    <ns>0</ns>
    <id>36964</id>
    <revision>
      <id>4657052</id>
      <parentid>4636826</parentid>
      <timestamp>2026-08-10T15:16:04Z</timestamp>
      <contributor>
        <username>JCrue</username>
        <id>2226064</id>
      </contributor>
      <comment>/* History */</comment>
      <origin>4657052</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="9389" sha1="s6na6ed3mhxltb54aic1mvh69nhmj48" xml:space="preserve">{{Chess Position|=
|Scandinavian defence|
|moves=1. e4 d5
|eco=[[Chess/ECOB|B01]]
|parent=[[../|King's pawn opening]]
}}

== 1...d5 · Scandinavian defence ==

Black takes on White's centre head on. They are determined to disrupt White's centre and immediately open up the board, even if they have to give up their own hopes of big centre and some tempo to do it. 

White could trade the pawn, defend it, or gambit it. 1...d5 is a very forcing response: almost invariably White captures, their plans derailed. 

=== Trade the pawn ===

[[/2. exd5|'''2. exd5''']] is almost always played. It's in White's interest to trade pawns. 

Usually Black recaptures with 2...Qxd5. This exposes the chief drawback of the Scandinavian. Developing one's queen too early makes it a vulnerability, and White can develop 3. Nc3 while gaining tempo on it. For this reason, the modern variation follows up with 2...Nf6, intending to trade off knights first so that 4...Qxd5 can't be met with 5. Nc3.

=== Defend the pawn ===

Trying to defend the e pawn comes with trade offs, ranging from small (2. d3?! or 2. Nc3?!) to severe (2...f3?). 

* [[/2. d3|'''2. d3?!''']] lets Black trade pawns then queens, and White loses the right to castle 2... dxe4 3. dxe4 Qxd1 4. Kxd1. Black's achieved equality and the nice open position they wanted but the game is drawish. After 2... dxe4, White can play 3. Nc3!? exd3 4. Bxe3, giving up all their central pawns for some development and transposing into something called the Dunst-Perrenet Gambit. 
* [[/2. Nc3|'''2. Nc3?!''']] allows 2...d4, kicking White's knight. 3. Nce2 e5 4. Ng3 and Black has a strong centre while White is cramped, but this leads to some tricky positions and offers White practical chances. Alternatively, 2...dxe4 results in a roughly equal position. 
* '''2. f3?''' defends e4 but is very unpleasant for White. If White intends 2... dxe4 3. fxe4, they may avoid the Scandinavian at the cost of a weakened kingside. However, if 2...e5 instead, leaving the tension, White's position is awful: they can't play Nf3 because their pawn is there, the king's bishop has no good squares, and Nc3 will be met by d4. White should probably play exd5 anyway, and end up the Scandinavian game they were wanting to avoid, but where they've also played f3. 
* [[/2. e5|'''2. e5?!''']] to avoid the pawn trade allows Black to clamp down on d4 with 2...c5, and/or play Bf5 then e6, achieving a superior [[Chess/French Defence|French defence]] structure without its passive bishop. 

=== Gambit the pawn ===

If White really wants to avoid the Scandinavian, then they'd do better to gambit the pawn instead. 

*[[/2. d4|'''2. d4?!''']] transposes into the '''Blackmar-Diemer gambit''', usually seen after 1.d4 d5. It has some chance of leading Black awry if they do not play 1...d5 against 1. d4. If Black prefers to decline the gambit, they can steer the game into the French, Caro-Kann, or Nimzowitsch defences.
* [[/2. Nf3|'''2. Nf3?!''']] is the '''Tennison gambit'''. At first it looks like a pre-move mistake, as 2... dxe4 will kick the knight. One plan for White is to win the pawn back only after getting ahead in development thanks to the threat on f7. It can lead to several tricky lines, including the internet-famous [[Chess Opening Theory/1. e4/1...d5/2. Nf3/2...dxe4/3. Ng5/3...Nf6/4. d3|Intercontinental Ballistic Missile Gambit]]. Alternatively Black can decline and transpose into a number of different openings. 

=== Bad moves ===

* 2. c3? allows White to regain the pawn after 2... dxe4 3. Qa4+. White decides that ''they'' would rather have their queen bullied about the board to give Black free tempi: 3...Nc6 4. Qxe4 Nf6 5. Qa4 and White is way behind in development.
* 2. b4? is called the '''Zilbermints gambit'''.

=== History ===
{{Chess/board|moves=1.e4 d5 2. exd5 Qxd5 3. Nc3 Qa5 4. d4 Nf6 5. Nf3 c6 6. Bd2 Bf5 |float=right|frame=1|caption=Position after 1.e4 d5 2. exd5 Qxd5 3. Nc3 Qa5 4. d4 Nf6 5. Nf3 c6 6. Bd2 Bf5 }}

1. e4 d5 is one of the oldest chess openings, described in a [[wikipedia:Scachs d'amor|15th Century Valencian poem]]. 

In the 19th and early 20th centuries this opening was known as '''centre-counter gambit'''.&lt;ref name=&quot;jaenisch&quot;&gt;{{Cite book |title=Jaenisch's chess preceptor: a new analysis of the openings of games |last=de Jaenisch |first=C. F. |publisher=Longman &amp; co. |year=1847 |location=London |url=https://archive.org/details/jaenischs-chess-preceptor |translator-last=Walker |translator-first=George|pages=40-1}} (translation of {{Cite book |title=Analyse nouvelle des ouvertures du jeu des échecs |last=de Jaenisch |first=C. F. |publisher=Gartner |year=1842}})&lt;/ref&gt;&lt;ref&gt;{{cite book |title=Chess Openings Ancient and Modern |last=Freeborough |first=E |last2=Ranken |first2=C. E. |year=1925 |publisher=David McKay |location=Philadelphia |page=244 |url=https://archive.org/details/chessopeningsanc0000free}}&lt;/ref&gt;

It is uncertain how the name &quot;Scandinavian&quot; originated. It may come from the 1897 Nordic Congress, held in Stockholm, Sweden, where the line was played by brothers Ludvig and Gustaf Collijn. It was used in German in the early 20th century&lt;ref&gt;Jacques Mieses wrote a monograph titled [https://catalog.hathitrust.org/Record/102734773 ''Die skandinavische Partie''] in 1918&lt;/ref&gt; and may have come to English from German chess literature. 

[[wikipedia:Bent Larsen|Bent Larsen]] revived the opening and defeated [[wikipedia:Anatoly Karpov|Anatoly Karpov]] with it in 1979.&lt;ref&gt;[https://www.chessgames.com/perl/chessgame?gid=1068107 Anatoly Karpov vs Bent Larsen, Montreal (1979). Chessgames.com]&lt;/ref&gt;

Its appeal to modern players is two-fold: firstly, 1...d5 is very forcing. Whereas with 1...e5, say, Black must be prepared to face a host of openings at White's choosing (the Italian, Spanish, Vienna, king's gambit, to name a few), after 1...d5 2. exd5 almost always occurs so Black dictates the course of play. They may reliably reach 2...Qxd4 3. Nc3 Qa4 almost every time they face 1. e4 if they choose. 

Secondly is the character of the typical Scandinavian pawn structure, which results in quieter and easy play for Black. Matthias Wahls writes on the popularity of the Scandinavian,&lt;ref name=&quot;Wahls&quot;&gt;{{Cite book |title=The Modern Scandinavian |last=Wahls |first=Matthias |publisher=New In Chess |year=2011 |isbn=9789056913441 |location=Alkmaar |last2=Muller |first2=Karsten |last3=Langrock |first3=Hannes}}&lt;/ref&gt;

&lt;blockquote&gt;In the majority of all cases, the same standard pawn centre appears with a white pawn on d4 and black pawns on e6 and c6. The stability of this pawn constellation confers a static character on the position. Sharp, forcing lines are the exception. The Scandinavian is unquestionably a model opening... You can also steer the course through the opening moves relatively easily without extensive theoretical knowledge, simply by making use of patterns and structural rules.
&lt;/blockquote&gt;

== Theory table ==
{{Chess Opening Theory/Table}}

{{Chess/theory table
|name1=Scandinavian defence, main line
|line1=2. exd5 Qxd5 3. Nc3 Qa5 4. d4 Nf6 5. Nf3 c6 6. Bd2 Bf5 
|eval1=&lt;nowiki&gt;=&lt;/nowiki&gt;
|name2=Lasker variation
|line2=2... ... 3. ... ... 4. ... ... 5. ... Bg4 6. h3 Qh5? 7. hxg4 Qxh1 8. Ne2 Nxg4 9. Ng3 Qxf1+ 10. Nxf1 
|eval2=+− 
|line3=2... ... 3. ... ... 4. ... ... 5. ... ... 6. ... Bh5 7. g4 Bg6 8. Ne5 Nbd7 9. Nc4 
|eval3=±

|name4=Leonhardt gambit
|line4=2... ... 3. ... ... 4. b4!? Qxb4 5. Rb1 Qd6 6. d4 Nf6 7. Nf3 
|eval4=&lt;nowiki&gt;=&lt;/nowiki&gt;
|line5=2... ... 3. ... ... 4. ... ... 5. Nb5 Qa5 6. Bc4 c6?? 7. Bxf7+ Kxf7 8. Qh5+ g6 9. Nd6+ exd6 10. Qxa5 
|eval5=+-
|line6=2... ... 3. ... ... 4. ... ... 5. ... ... 6. ... Nf6
|eval6=⩱

|name7=Modern Scandinavian
|line7=2... Nf6 3. d4 
|name8=Marshall variation
|line8=2... ... 3. ... Nxd5 4. Nf3 Bf5 5. Bd3 Bxd3 6. Qxd3 e6 7. O-O 
|name9=Richter variation
|line9=2... ... 3. ... ... 4. ... g6 5. c4 Nb6 6. Nc3 Bg7 7. Be2 O-O 8. O-O 
|eval9=⩲
|name10=Gipslis variation
|line10=2... ... 3. ... ... 4. ... Bg4 5. Be2 e6 6. O-O Nc6 7. c4 Nb6 8. Nc3 Be7 9. d5 
|name11=Portuguese gambit
|line11=2... ... 3. ... Bg4 4. f3 Bf5 
|line12=2... ... 3. Nc3?! Nxd5 4. Nxd5 Qxd5 5. d4 
|eval12=&lt;nowiki&gt;=&lt;/nowiki&gt;
	
|name13=Blackburne-Kloosterboer gambit
|line13=2...c6

|name14=Tennison gambit
|line14=2. Nf3 dxe4 3. Ng5 Nf6 4. Bc4 e6 5. Nc3 Qd4 6. Qe2 
|eval14=&lt;nowiki&gt;=&lt;/nowiki&gt;
|name15=Intercontinental ballistic missile&lt;br /&gt;gambit accepted
|line15=2. ... ... 3. ... ... 4. d3 exd3 5. Bxd3 h6?? 6. Nxf7 Kxf7 7. Bg6+ Kxg6 8. Qxd8 
|eval15=+/-
|line16=2. ... ... 3. ... ... 4. ... ... 5. ... e5?? 6. Bb5+ c6 7. Qxd8+ Kxd8 8. Nxf7+ 
|eval16=+/-

|name17=Blackmar-Diemer gambit&lt;br&gt;&lt;small&gt;(by transposition)&lt;/small&gt;
|line17=2. d4 dxe4 3. Nc3 Nf6 4. f3 exf3 5. Nxf3 g6 6. Bc4 Bg7 
|name18=Ryder gambit
|line18=2. ... ... 3. ... ... 4. ... ... 5. Qxf3!? Qxd4 

|line19=2. Nc3 d4 3. Nce2 e5 4. Ng3 Be6
|name19=Lizard attack
|eval19={{chess/not|unclear}}

|line20=2. d3?! dxe4 3. Nc3 exd3 4. Bxd3 Nc6 5. Bg5 h6 6. Bh4 Nf6 7. Nf3 g5 8. Bg3 Bg7 9. Qe2
|name20=Dunst Perrenet gambit&lt;br&gt;&lt;small&gt;(by transposition)&lt;/small&gt;
|eval20={{chess/not}}

|line21=2...Nc6 3. Nd2 Nf6 4. Ngf3 e5 5. Be2 
|name21=Inverted Hanham defence&lt;br&gt;&lt;small&gt;(by transposition)&lt;/small&gt;
|eval21={{chess/not}}

}}

{{ChessMid}}

== References ==
{{Wikipedia|Center Counter Defence}}
{{reflist}}
{{NCO}}
{{BCO2}}
{{Chess Opening Theory/Footer}}</text>
      <sha1>s6na6ed3mhxltb54aic1mvh69nhmj48</sha1>
    </revision>
    <revision>
      <id>4657056</id>
      <parentid>4657052</parentid>
      <timestamp>2026-08-10T15:30:48Z</timestamp>
      <contributor>
        <username>JCrue</username>
        <id>2226064</id>
      </contributor>
      <comment>/* History */</comment>
      <origin>4657056</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="9857" sha1="9d58ejehzruv8t0ijwjmyqj9wqoyc7e" xml:space="preserve">{{Chess Position|=
|Scandinavian defence|
|moves=1. e4 d5
|eco=[[Chess/ECOB|B01]]
|parent=[[../|King's pawn opening]]
}}

== 1...d5 · Scandinavian defence ==

Black takes on White's centre head on. They are determined to disrupt White's centre and immediately open up the board, even if they have to give up their own hopes of big centre and some tempo to do it. 

White could trade the pawn, defend it, or gambit it. 1...d5 is a very forcing response: almost invariably White captures, their plans derailed. 

=== Trade the pawn ===

[[/2. exd5|'''2. exd5''']] is almost always played. It's in White's interest to trade pawns. 

Usually Black recaptures with 2...Qxd5. This exposes the chief drawback of the Scandinavian. Developing one's queen too early makes it a vulnerability, and White can develop 3. Nc3 while gaining tempo on it. For this reason, the modern variation follows up with 2...Nf6, intending to trade off knights first so that 4...Qxd5 can't be met with 5. Nc3.

=== Defend the pawn ===

Trying to defend the e pawn comes with trade offs, ranging from small (2. d3?! or 2. Nc3?!) to severe (2...f3?). 

* [[/2. d3|'''2. d3?!''']] lets Black trade pawns then queens, and White loses the right to castle 2... dxe4 3. dxe4 Qxd1 4. Kxd1. Black's achieved equality and the nice open position they wanted but the game is drawish. After 2... dxe4, White can play 3. Nc3!? exd3 4. Bxe3, giving up all their central pawns for some development and transposing into something called the Dunst-Perrenet Gambit. 
* [[/2. Nc3|'''2. Nc3?!''']] allows 2...d4, kicking White's knight. 3. Nce2 e5 4. Ng3 and Black has a strong centre while White is cramped, but this leads to some tricky positions and offers White practical chances. Alternatively, 2...dxe4 results in a roughly equal position. 
* '''2. f3?''' defends e4 but is very unpleasant for White. If White intends 2... dxe4 3. fxe4, they may avoid the Scandinavian at the cost of a weakened kingside. However, if 2...e5 instead, leaving the tension, White's position is awful: they can't play Nf3 because their pawn is there, the king's bishop has no good squares, and Nc3 will be met by d4. White should probably play exd5 anyway, and end up the Scandinavian game they were wanting to avoid, but where they've also played f3. 
* [[/2. e5|'''2. e5?!''']] to avoid the pawn trade allows Black to clamp down on d4 with 2...c5, and/or play Bf5 then e6, achieving a superior [[Chess/French Defence|French defence]] structure without its passive bishop. 

=== Gambit the pawn ===

If White really wants to avoid the Scandinavian, then they'd do better to gambit the pawn instead. 

*[[/2. d4|'''2. d4?!''']] transposes into the '''Blackmar-Diemer gambit''', usually seen after 1.d4 d5. It has some chance of leading Black awry if they do not play 1...d5 against 1. d4. If Black prefers to decline the gambit, they can steer the game into the French, Caro-Kann, or Nimzowitsch defences.
* [[/2. Nf3|'''2. Nf3?!''']] is the '''Tennison gambit'''. At first it looks like a pre-move mistake, as 2... dxe4 will kick the knight. One plan for White is to win the pawn back only after getting ahead in development thanks to the threat on f7. It can lead to several tricky lines, including the internet-famous [[Chess Opening Theory/1. e4/1...d5/2. Nf3/2...dxe4/3. Ng5/3...Nf6/4. d3|Intercontinental Ballistic Missile Gambit]]. Alternatively Black can decline and transpose into a number of different openings. 

=== Bad moves ===

* 2. c3? allows White to regain the pawn after 2... dxe4 3. Qa4+. White decides that ''they'' would rather have their queen bullied about the board to give Black free tempi: 3...Nc6 4. Qxe4 Nf6 5. Qa4 and White is way behind in development.
* 2. b4? is called the '''Zilbermints gambit'''.

=== History ===
{{Chess/board|moves=1.e4 d5 2. exd5 Qxd5 3. Nc3 Qa5 4. d4 Nf6 5. Nf3 c6 6. Bd2 Bf5 |float=right|frame=1|caption=Position after 1.e4 d5 2. exd5 Qxd5 3. Nc3 Qa5 4. d4 Nf6 5. Nf3 c6 6. Bd2 Bf5 }}

1. e4 d5 is one of the oldest chess openings, described in a [[wikipedia:Scachs d'amor|15th Century Valencian poem]]. 

In the 19th and early 20th centuries this opening was known as '''centre-counter gambit'''.&lt;ref name=&quot;jaenisch&quot;&gt;{{Cite book |title=Jaenisch's chess preceptor: a new analysis of the openings of games |last=de Jaenisch |first=C. F. |publisher=Longman &amp; co. |year=1847 |location=London |url=https://archive.org/details/jaenischs-chess-preceptor |translator-last=Walker |translator-first=George|pages=40-1}} (translation of {{Cite book |title=Analyse nouvelle des ouvertures du jeu des échecs |last=de Jaenisch |first=C. F. |publisher=Gartner |year=1842}})&lt;/ref&gt;&lt;ref&gt;{{cite book |title=Chess Openings Ancient and Modern |last=Freeborough |first=E |last2=Ranken |first2=C. E. |year=1925 |publisher=David McKay |location=Philadelphia |page=244 |url=https://archive.org/details/chessopeningsanc0000free}}&lt;/ref&gt; It was not very well regarded at the time: the ''Handbuch'' doesn't give the line a name but does give the move 1...d5 and question mark and the criticism, &quot;this move is not good, as White gains a tempo&quot; (translated from German).&lt;ref&gt;{{Cite book |title=Handbuch des Schachspiels |last=von Biluger |first=P. R. |publisher=Verlag Von Veit &amp; Comp. |year=1891 |edition=7th |location=Leipzig |pages=662-663|url=https://archive.org/details/handbuchdesscha00schagoog}}&lt;/ref&gt;

It is uncertain how the name &quot;Scandinavian&quot; originated. It may come from the 1897 Nordic Congress, held in Stockholm, Sweden, where the line was played by brothers Ludvig and Gustaf Collijn. It was used in German in the early 20th century&lt;ref&gt;Jacques Mieses wrote a monograph titled [https://catalog.hathitrust.org/Record/102734773 ''Die skandinavische Partie''] in 1918&lt;/ref&gt; and may have come to English from German chess literature. 

[[wikipedia:Bent Larsen|Bent Larsen]] revived the opening and defeated [[wikipedia:Anatoly Karpov|Anatoly Karpov]] with it in 1979.&lt;ref&gt;[https://www.chessgames.com/perl/chessgame?gid=1068107 Anatoly Karpov vs Bent Larsen, Montreal (1979). Chessgames.com]&lt;/ref&gt;

Its appeal to modern players is two-fold: firstly, 1...d5 is very forcing. Whereas with 1...e5, say, Black must be prepared to face a host of openings at White's choosing (the Italian, Spanish, Vienna, king's gambit, to name a few), after 1...d5 2. exd5 almost always occurs so Black dictates the course of play. They may reliably reach 2...Qxd4 3. Nc3 Qa4 almost every time they face 1. e4 if they choose. 

Secondly is the character of the typical Scandinavian pawn structure, which results in quieter and easy play for Black. Matthias Wahls writes on the popularity of the Scandinavian,&lt;ref name=&quot;Wahls&quot;&gt;{{Cite book |title=The Modern Scandinavian |last=Wahls |first=Matthias |publisher=New In Chess |year=2011 |isbn=9789056913441 |location=Alkmaar |last2=Muller |first2=Karsten |last3=Langrock |first3=Hannes}}&lt;/ref&gt;

&lt;blockquote&gt;In the majority of all cases, the same standard pawn centre appears with a white pawn on d4 and black pawns on e6 and c6. The stability of this pawn constellation confers a static character on the position. Sharp, forcing lines are the exception. The Scandinavian is unquestionably a model opening... You can also steer the course through the opening moves relatively easily without extensive theoretical knowledge, simply by making use of patterns and structural rules.
&lt;/blockquote&gt;

== Theory table ==
{{Chess Opening Theory/Table}}

{{Chess/theory table
|name1=Scandinavian defence, main line
|line1=2. exd5 Qxd5 3. Nc3 Qa5 4. d4 Nf6 5. Nf3 c6 6. Bd2 Bf5 
|eval1=&lt;nowiki&gt;=&lt;/nowiki&gt;
|name2=Lasker variation
|line2=2... ... 3. ... ... 4. ... ... 5. ... Bg4 6. h3 Qh5? 7. hxg4 Qxh1 8. Ne2 Nxg4 9. Ng3 Qxf1+ 10. Nxf1 
|eval2=+− 
|line3=2... ... 3. ... ... 4. ... ... 5. ... ... 6. ... Bh5 7. g4 Bg6 8. Ne5 Nbd7 9. Nc4 
|eval3=±

|name4=Leonhardt gambit
|line4=2... ... 3. ... ... 4. b4!? Qxb4 5. Rb1 Qd6 6. d4 Nf6 7. Nf3 
|eval4=&lt;nowiki&gt;=&lt;/nowiki&gt;
|line5=2... ... 3. ... ... 4. ... ... 5. Nb5 Qa5 6. Bc4 c6?? 7. Bxf7+ Kxf7 8. Qh5+ g6 9. Nd6+ exd6 10. Qxa5 
|eval5=+-
|line6=2... ... 3. ... ... 4. ... ... 5. ... ... 6. ... Nf6
|eval6=⩱

|name7=Modern Scandinavian
|line7=2... Nf6 3. d4 
|name8=Marshall variation
|line8=2... ... 3. ... Nxd5 4. Nf3 Bf5 5. Bd3 Bxd3 6. Qxd3 e6 7. O-O 
|name9=Richter variation
|line9=2... ... 3. ... ... 4. ... g6 5. c4 Nb6 6. Nc3 Bg7 7. Be2 O-O 8. O-O 
|eval9=⩲
|name10=Gipslis variation
|line10=2... ... 3. ... ... 4. ... Bg4 5. Be2 e6 6. O-O Nc6 7. c4 Nb6 8. Nc3 Be7 9. d5 
|name11=Portuguese gambit
|line11=2... ... 3. ... Bg4 4. f3 Bf5 
|line12=2... ... 3. Nc3?! Nxd5 4. Nxd5 Qxd5 5. d4 
|eval12=&lt;nowiki&gt;=&lt;/nowiki&gt;
	
|name13=Blackburne-Kloosterboer gambit
|line13=2...c6

|name14=Tennison gambit
|line14=2. Nf3 dxe4 3. Ng5 Nf6 4. Bc4 e6 5. Nc3 Qd4 6. Qe2 
|eval14=&lt;nowiki&gt;=&lt;/nowiki&gt;
|name15=Intercontinental ballistic missile&lt;br /&gt;gambit accepted
|line15=2. ... ... 3. ... ... 4. d3 exd3 5. Bxd3 h6?? 6. Nxf7 Kxf7 7. Bg6+ Kxg6 8. Qxd8 
|eval15=+/-
|line16=2. ... ... 3. ... ... 4. ... ... 5. ... e5?? 6. Bb5+ c6 7. Qxd8+ Kxd8 8. Nxf7+ 
|eval16=+/-

|name17=Blackmar-Diemer gambit&lt;br&gt;&lt;small&gt;(by transposition)&lt;/small&gt;
|line17=2. d4 dxe4 3. Nc3 Nf6 4. f3 exf3 5. Nxf3 g6 6. Bc4 Bg7 
|name18=Ryder gambit
|line18=2. ... ... 3. ... ... 4. ... ... 5. Qxf3!? Qxd4 

|line19=2. Nc3 d4 3. Nce2 e5 4. Ng3 Be6
|name19=Lizard attack
|eval19={{chess/not|unclear}}

|line20=2. d3?! dxe4 3. Nc3 exd3 4. Bxd3 Nc6 5. Bg5 h6 6. Bh4 Nf6 7. Nf3 g5 8. Bg3 Bg7 9. Qe2
|name20=Dunst Perrenet gambit&lt;br&gt;&lt;small&gt;(by transposition)&lt;/small&gt;
|eval20={{chess/not}}

|line21=2...Nc6 3. Nd2 Nf6 4. Ngf3 e5 5. Be2 
|name21=Inverted Hanham defence&lt;br&gt;&lt;small&gt;(by transposition)&lt;/small&gt;
|eval21={{chess/not}}

}}

{{ChessMid}}

== References ==
{{Wikipedia|Center Counter Defence}}
{{reflist}}
{{NCO}}
{{BCO2}}
{{Chess Opening Theory/Footer}}</text>
      <sha1>9d58ejehzruv8t0ijwjmyqj9wqoyc7e</sha1>
    </revision>
    <revision>
      <id>4657062</id>
      <parentid>4657056</parentid>
      <timestamp>2026-08-10T15:48:13Z</timestamp>
      <contributor>
        <username>JCrue</username>
        <id>2226064</id>
      </contributor>
      <minor />
      <comment>/* History */</comment>
      <origin>4657062</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="9863" sha1="nkr1i2zdb78cgx69l3ddpyplk2xj9n0" xml:space="preserve">{{Chess Position|=
|Scandinavian defence|
|moves=1. e4 d5
|eco=[[Chess/ECOB|B01]]
|parent=[[../|King's pawn opening]]
}}

== 1...d5 · Scandinavian defence ==

Black takes on White's centre head on. They are determined to disrupt White's centre and immediately open up the board, even if they have to give up their own hopes of big centre and some tempo to do it. 

White could trade the pawn, defend it, or gambit it. 1...d5 is a very forcing response: almost invariably White captures, their plans derailed. 

=== Trade the pawn ===

[[/2. exd5|'''2. exd5''']] is almost always played. It's in White's interest to trade pawns. 

Usually Black recaptures with 2...Qxd5. This exposes the chief drawback of the Scandinavian. Developing one's queen too early makes it a vulnerability, and White can develop 3. Nc3 while gaining tempo on it. For this reason, the modern variation follows up with 2...Nf6, intending to trade off knights first so that 4...Qxd5 can't be met with 5. Nc3.

=== Defend the pawn ===

Trying to defend the e pawn comes with trade offs, ranging from small (2. d3?! or 2. Nc3?!) to severe (2...f3?). 

* [[/2. d3|'''2. d3?!''']] lets Black trade pawns then queens, and White loses the right to castle 2... dxe4 3. dxe4 Qxd1 4. Kxd1. Black's achieved equality and the nice open position they wanted but the game is drawish. After 2... dxe4, White can play 3. Nc3!? exd3 4. Bxe3, giving up all their central pawns for some development and transposing into something called the Dunst-Perrenet Gambit. 
* [[/2. Nc3|'''2. Nc3?!''']] allows 2...d4, kicking White's knight. 3. Nce2 e5 4. Ng3 and Black has a strong centre while White is cramped, but this leads to some tricky positions and offers White practical chances. Alternatively, 2...dxe4 results in a roughly equal position. 
* '''2. f3?''' defends e4 but is very unpleasant for White. If White intends 2... dxe4 3. fxe4, they may avoid the Scandinavian at the cost of a weakened kingside. However, if 2...e5 instead, leaving the tension, White's position is awful: they can't play Nf3 because their pawn is there, the king's bishop has no good squares, and Nc3 will be met by d4. White should probably play exd5 anyway, and end up the Scandinavian game they were wanting to avoid, but where they've also played f3. 
* [[/2. e5|'''2. e5?!''']] to avoid the pawn trade allows Black to clamp down on d4 with 2...c5, and/or play Bf5 then e6, achieving a superior [[Chess/French Defence|French defence]] structure without its passive bishop. 

=== Gambit the pawn ===

If White really wants to avoid the Scandinavian, then they'd do better to gambit the pawn instead. 

*[[/2. d4|'''2. d4?!''']] transposes into the '''Blackmar-Diemer gambit''', usually seen after 1.d4 d5. It has some chance of leading Black awry if they do not play 1...d5 against 1. d4. If Black prefers to decline the gambit, they can steer the game into the French, Caro-Kann, or Nimzowitsch defences.
* [[/2. Nf3|'''2. Nf3?!''']] is the '''Tennison gambit'''. At first it looks like a pre-move mistake, as 2... dxe4 will kick the knight. One plan for White is to win the pawn back only after getting ahead in development thanks to the threat on f7. It can lead to several tricky lines, including the internet-famous [[Chess Opening Theory/1. e4/1...d5/2. Nf3/2...dxe4/3. Ng5/3...Nf6/4. d3|Intercontinental Ballistic Missile Gambit]]. Alternatively Black can decline and transpose into a number of different openings. 

=== Bad moves ===

* 2. c3? allows White to regain the pawn after 2... dxe4 3. Qa4+. White decides that ''they'' would rather have their queen bullied about the board to give Black free tempi: 3...Nc6 4. Qxe4 Nf6 5. Qa4 and White is way behind in development.
* 2. b4? is called the '''Zilbermints gambit'''.

=== History ===
{{Chess/board|moves=1.e4 d5 2. exd5 Qxd5 3. Nc3 Qa5 4. d4 Nf6 5. Nf3 c6 6. Bd2 Bf5 |float=right|frame=1|caption=Position after 1.e4 d5 2. exd5 Qxd5 3. Nc3 Qa5 4. d4 Nf6 5. Nf3 c6 6. Bd2 Bf5 }}

1. e4 d5 is one of the oldest chess openings, described in a [[wikipedia:Scachs d'amor|15th Century Valencian poem]]. 

In the 19th and early 20th centuries this opening was known as '''centre-counter gambit'''.&lt;ref name=&quot;jaenisch&quot;&gt;{{Cite book |title=Jaenisch's chess preceptor: a new analysis of the openings of games |last=de Jaenisch |first=C. F. |publisher=Longman &amp; co. |year=1847 |location=London |url=https://archive.org/details/jaenischs-chess-preceptor |translator-last=Walker |translator-first=George|pages=40-1}} (translation of {{Cite book |title=Analyse nouvelle des ouvertures du jeu des échecs |last=de Jaenisch |first=C. F. |publisher=Gartner |year=1842}})&lt;/ref&gt;&lt;ref&gt;{{cite book |title=Chess Openings Ancient and Modern |last=Freeborough |first=E |last2=Ranken |first2=C. E. |year=1925 |publisher=David McKay |location=Philadelphia |page=244 |url=https://archive.org/details/chessopeningsanc0000free}}&lt;/ref&gt; It was not very well regarded at the time: the ''Handbuch'' doesn't give the line a name but does give the move 1...d5 and question mark and the criticism, &quot;this move is not good, as White gains a tempo&quot; (translated from German).&lt;ref&gt;{{Cite book |title=Handbuch des Schachspiels |last=von Biluger |first=P. R. |publisher=Verlag Von Veit &amp; Comp. |year=1891 |edition=7th |location=Leipzig |pages=662-663|url=https://archive.org/details/handbuchdesscha00schagoog}}&lt;/ref&gt;

It is uncertain how the name &quot;Scandinavian&quot; originated. It may come from the 1897 Nordic Congress, held in Stockholm, Sweden, where the line was played by brothers Ludvig and Gustaf Collijn. The term was used in German in the early 20th century&lt;ref&gt;Jacques Mieses wrote a monograph titled [https://catalog.hathitrust.org/Record/102734773 ''Die skandinavische Partie''] in 1918&lt;/ref&gt; and may have come to English from German chess literature. 

[[wikipedia:Bent Larsen|Bent Larsen]] revived the opening and defeated [[wikipedia:Anatoly Karpov|Anatoly Karpov]] with it in 1979.&lt;ref&gt;[https://www.chessgames.com/perl/chessgame?gid=1068107 Anatoly Karpov vs Bent Larsen, Montreal (1979). Chessgames.com]&lt;/ref&gt;

Its appeal to modern players is two-fold: firstly, 1...d5 is very forcing. Whereas with 1...e5, say, Black must be prepared to face a host of openings at White's choosing (the Italian, Spanish, Vienna, king's gambit, to name a few), after 1...d5 2. exd5 almost always occurs so Black dictates the course of play. They may reliably reach 2...Qxd4 3. Nc3 Qa4 almost every time they face 1. e4 if they choose. 

Secondly is the character of the typical Scandinavian pawn structure, which results in quieter and easy play for Black. Matthias Wahls writes on the popularity of the Scandinavian,&lt;ref name=&quot;Wahls&quot;&gt;{{Cite book |title=The Modern Scandinavian |last=Wahls |first=Matthias |publisher=New In Chess |year=2011 |isbn=9789056913441 |location=Alkmaar |last2=Muller |first2=Karsten |last3=Langrock |first3=Hannes}}&lt;/ref&gt;

&lt;blockquote&gt;In the majority of all cases, the same standard pawn centre appears with a white pawn on d4 and black pawns on e6 and c6. The stability of this pawn constellation confers a static character on the position. Sharp, forcing lines are the exception. The Scandinavian is unquestionably a model opening... You can also steer the course through the opening moves relatively easily without extensive theoretical knowledge, simply by making use of patterns and structural rules.
&lt;/blockquote&gt;

== Theory table ==
{{Chess Opening Theory/Table}}

{{Chess/theory table
|name1=Scandinavian defence, main line
|line1=2. exd5 Qxd5 3. Nc3 Qa5 4. d4 Nf6 5. Nf3 c6 6. Bd2 Bf5 
|eval1=&lt;nowiki&gt;=&lt;/nowiki&gt;
|name2=Lasker variation
|line2=2... ... 3. ... ... 4. ... ... 5. ... Bg4 6. h3 Qh5? 7. hxg4 Qxh1 8. Ne2 Nxg4 9. Ng3 Qxf1+ 10. Nxf1 
|eval2=+− 
|line3=2... ... 3. ... ... 4. ... ... 5. ... ... 6. ... Bh5 7. g4 Bg6 8. Ne5 Nbd7 9. Nc4 
|eval3=±

|name4=Leonhardt gambit
|line4=2... ... 3. ... ... 4. b4!? Qxb4 5. Rb1 Qd6 6. d4 Nf6 7. Nf3 
|eval4=&lt;nowiki&gt;=&lt;/nowiki&gt;
|line5=2... ... 3. ... ... 4. ... ... 5. Nb5 Qa5 6. Bc4 c6?? 7. Bxf7+ Kxf7 8. Qh5+ g6 9. Nd6+ exd6 10. Qxa5 
|eval5=+-
|line6=2... ... 3. ... ... 4. ... ... 5. ... ... 6. ... Nf6
|eval6=⩱

|name7=Modern Scandinavian
|line7=2... Nf6 3. d4 
|name8=Marshall variation
|line8=2... ... 3. ... Nxd5 4. Nf3 Bf5 5. Bd3 Bxd3 6. Qxd3 e6 7. O-O 
|name9=Richter variation
|line9=2... ... 3. ... ... 4. ... g6 5. c4 Nb6 6. Nc3 Bg7 7. Be2 O-O 8. O-O 
|eval9=⩲
|name10=Gipslis variation
|line10=2... ... 3. ... ... 4. ... Bg4 5. Be2 e6 6. O-O Nc6 7. c4 Nb6 8. Nc3 Be7 9. d5 
|name11=Portuguese gambit
|line11=2... ... 3. ... Bg4 4. f3 Bf5 
|line12=2... ... 3. Nc3?! Nxd5 4. Nxd5 Qxd5 5. d4 
|eval12=&lt;nowiki&gt;=&lt;/nowiki&gt;
	
|name13=Blackburne-Kloosterboer gambit
|line13=2...c6

|name14=Tennison gambit
|line14=2. Nf3 dxe4 3. Ng5 Nf6 4. Bc4 e6 5. Nc3 Qd4 6. Qe2 
|eval14=&lt;nowiki&gt;=&lt;/nowiki&gt;
|name15=Intercontinental ballistic missile&lt;br /&gt;gambit accepted
|line15=2. ... ... 3. ... ... 4. d3 exd3 5. Bxd3 h6?? 6. Nxf7 Kxf7 7. Bg6+ Kxg6 8. Qxd8 
|eval15=+/-
|line16=2. ... ... 3. ... ... 4. ... ... 5. ... e5?? 6. Bb5+ c6 7. Qxd8+ Kxd8 8. Nxf7+ 
|eval16=+/-

|name17=Blackmar-Diemer gambit&lt;br&gt;&lt;small&gt;(by transposition)&lt;/small&gt;
|line17=2. d4 dxe4 3. Nc3 Nf6 4. f3 exf3 5. Nxf3 g6 6. Bc4 Bg7 
|name18=Ryder gambit
|line18=2. ... ... 3. ... ... 4. ... ... 5. Qxf3!? Qxd4 

|line19=2. Nc3 d4 3. Nce2 e5 4. Ng3 Be6
|name19=Lizard attack
|eval19={{chess/not|unclear}}

|line20=2. d3?! dxe4 3. Nc3 exd3 4. Bxd3 Nc6 5. Bg5 h6 6. Bh4 Nf6 7. Nf3 g5 8. Bg3 Bg7 9. Qe2
|name20=Dunst Perrenet gambit&lt;br&gt;&lt;small&gt;(by transposition)&lt;/small&gt;
|eval20={{chess/not}}

|line21=2...Nc6 3. Nd2 Nf6 4. Ngf3 e5 5. Be2 
|name21=Inverted Hanham defence&lt;br&gt;&lt;small&gt;(by transposition)&lt;/small&gt;
|eval21={{chess/not}}

}}

{{ChessMid}}

== References ==
{{Wikipedia|Center Counter Defence}}
{{reflist}}
{{NCO}}
{{BCO2}}
{{Chess Opening Theory/Footer}}</text>
      <sha1>nkr1i2zdb78cgx69l3ddpyplk2xj9n0</sha1>
    </revision>
  </page>
  <page>
    <title>Chess Opening Theory/1. e4/1...c5/2. Nf3/2...e6</title>
    <ns>0</ns>
    <id>41896</id>
    <revision>
      <id>4657065</id>
      <parentid>4637770</parentid>
      <timestamp>2026-08-10T15:59:55Z</timestamp>
      <contributor>
        <username>JCrue</username>
        <id>2226064</id>
      </contributor>
      <origin>4657065</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="4011" sha1="nhzgwjpzkjutfzgxms3sphrskfyajw4" xml:space="preserve">{{Chess Position
|name=French Sicilian
|eco=[[Chess/ECOB|B40]]
|parent=[[Chess Opening Theory/1. e4/1...c5|Sicilian defence]] → [[../|2. Nf3]]
}}
== 2...e6 · French Sicilian ==
Black opens up the a3-f8 diagonal for their dark squared bishop, while also controlling the d5 square for a second time. This prepares to play ...d5 and recapture with a pawn, gaining further central control. 

=== Open the centre ===

[[/3. d4|'''3. d4''']] is the main move. This is the standard '''open Sicilian''' plan: 3...cxd4 4. Nxd4. The centre is open and both of White's bishops are ready to come into the game. Then Black has a choice of how to proceed: the main French Sicilians are the Kan, Paulsen, Taimanov, or four knights variations. 

[[/3. Nc3|'''3. Nc3''']] is also possible. This postpones d4 while White waits for more information on which Sicilian Black will choose.  

=== Anti-Sicilians ===

There is also a variety of &quot;anti-Sicilians&quot; (Sicilians that aren't the open Sicilian) available to White, avoiding the main line and aiming to exploit the fact that 2...e6 blocked Black's c8 bishop. Against 2...d6 or 2...Nc6, the main anti-Sicilian is 3. Bb5, but it is not so effective here following 2...e6. If White still wishes to avoid the open Sicilian, they might opt for one of the following instead. 

[[/3. c3|'''3. c3''']] is the '''delayed Alapin Sicilian'''. The idea is to support playing d4 and keep the pawn there. While similar in character to the Alapin played on turn two (1. e4 c5 2. c3), playing c3 on the third move, after Black has committed a pawn to 2...e6, means Black has different options for how to proceed.

[[/3. c4|'''3. c4''']] is the '''Kramnik Sicilian''', creating a &quot;Maroczy bind&quot; position where White contests the d5 square. 

[[/3. b3|'''3. b3''']] is the '''Westerinen attack''', preparing to fianchetto the bishop. 

[[/3. d3|'''3. d3''']] may lead to a '''king's Indian'''-type position. White recognises that the position is a bit like a French defence (1. e4 e6), just where Black has already played ...c5 and hasn't gotten to ...d5 yet. White may start with '''3. Qe2''' or '''3. g3''' and reach the same set-up. 

=== History ===

[[w:Carl Jaenisch|Carl Jaenisch]] (1813―1872) may have been the first one to give this the name &quot;French&quot;. In his 19th century treatise on chess, he grouped together 1...c5 followed by 2...e6 (2...e6 was the main variation at the time) with 1...e6 as the &quot;French Openings&quot;, writing, &quot;Far from being 'irregular,' they afford a line of defence more secure than [1...e5], but the Kings being severally less exposed, the game becomes much more tedious.&quot;&lt;ref name=&quot;jaenisch&quot;&gt;{{Cite book |title=Jaenisch's chess preceptor: a new analysis of the openings of games |last=de Jaenisch |first=C. F. |publisher=Longman &amp; co. |year=1847 |location=London |url=https://archive.org/details/jaenischs-chess-preceptor |translator-last=Walker |translator-first=George}} (translation of {{Cite book |title=Analyse nouvelle des ouvertures du jeu des échecs |last=de Jaenisch |first=C. F. |publisher=Gartner |year=1842}})&lt;/ref&gt;

==Theory table==
{{Chess Opening Theory/Table}}

{{Chess/theory table 
|line1=3. d4 cxd4 4. Nxd4 a6 5. Bd3 Bc5 6. Nb3 Be7 7. Qg4 g6 8. Qe2 d6 9. O-O Nd7 10. Nc3 Qc7
|name1=Kan variation
|line2=3. ... ... 4. ... Nc6 5. Nc3 Qc7 6. Be3 a6 7. Qd2 Nf6 8. O-O-O Bb4 9. f3 Ne5 10. Nb3 b5 
|name2=Taimanov variation
|line3=3. ... ... 4. ... Nf6 5. Nc3 d6 6. g4 h6 7. h4 Nc6 8. Rg1 h5 9. gxh5 Nxh5 10. Bg5 Nf6 
|name3=Scheveningen variation
|line4=3. ... ... 4. ... Qb6 5. Nb3 Qc7 6. Bd3 Nf6 
|name4=Kveinis variation
|line5=3. ... ... 4. ... Bc5 5. Nb3 Bb6 6. Nc3 Ne7 
|name5=Paulsen-Basman defence
|line6=3. c3 d5 4. exd5 exd5 5. d4 Nc6 6. Bb5 Bd6 
|name6=Delayed Alapin
|line7=3. c4 Nc6 4. Nc3 Nf6 5. Be2 d5 6. exd5 exd5 7. d4 Be6 
|name7=Kramnik variation
}}

{{ChessMid}}
==References==
{{reflist}}
=== See also===
{{Wikipedia|Sicilian Defence}}

{{Chess Opening Theory/Footer}}

[[fi:Shakkiaapinen/Peli/1. e4/1...c5/2. Rf3/2...e6]]</text>
      <sha1>nhzgwjpzkjutfzgxms3sphrskfyajw4</sha1>
    </revision>
  </page>
  <page>
    <title>Rhetoric and Composition/Types of Sentences</title>
    <ns>0</ns>
    <id>46097</id>
    <revision>
      <id>4657146</id>
      <parentid>3552102</parentid>
      <timestamp>2026-08-11T08:39:52Z</timestamp>
      <contributor>
        <username>~2026-44153-75</username>
        <id>3620665</id>
      </contributor>
      <comment>/* Sentence Structure */</comment>
      <origin>4657146</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="5268" sha1="9e7ys0nr66aedrqs5b7mqmjitslrk2l" xml:space="preserve">There are several different types of sentences.  Each is classified based on its structure and purpose.

==Sentence Structure==
Using a variety of sentences helps the reader follow the flow of a writer’s thoughts. Choosing between simple, compound, complex, and compound-complex sentences and mixing them up throughout the material will keep the reader interested. Varying the length of the sentences also keeps the reader involved.

Reading material that marches along becomes tedious. For example:

''The band marched along the street, and the director signaled for the drums to play. A red car stopped at the intersection, and the parents walked beside the band. The parents squirted water into the musicians’ mouths, and the trumpet players started to play. The band marched past the intersection, and the red car proceeded down the street''.  

Reading this group of compound sentences becomes boring. If the writer mixes up the types of sentences like the example below, the sentences will flow more easily for the reader. 

''As the band marched along the street, the director signaled for the drums to play. A red car stopped at the intersection. While the parents walked beside the band, they squirted water into the trumpet players’ mouths. The trumpet players started to play. The band marched past the intersection, and the red car proceeded down the street.''  

The first sentence is complex, and the second one is simple. The third is again complex while the fourth is simple. The fifth sentence is compound. The choppiness is gone, and a flow is created.

Sentence structure is determined based on the number of clauses in the sentence.  A clause can be independent or subordinate.

===Independent clause===

* Full sentence pattern that can operate on its own and does not function within another sentence pattern.
* Contains a subject plus a verb and any objects, any modifiers.
*It either stands alone or could stand alone.
--Example: '''May studied in the library for her final exam'''.

===Subordinate clause===

*Pattern like a full sentence (has subjects and verbs) but functions within a sentence.
*Can function as a noun, adjective or adverb.
*Can not stand alone as a complete sentence.
*Sometimes called a dependent clause.
--Example: '''After May studied in the library for her final exam''', she went home.

===Complement Clause===
*Ordinary --- If you examine the structure of the entire sentence, you will see that this complement clause is taking the place of a direct object.  This is common for ordinary complement clauses.  Certain verbs, which your text goes into in detail, allow this. 
-- Example:     I know [that James went to Yale]. 
*Noun --- In a noun complement clause construction, the complement clause occurs after a noun.  The number of nouns that can be used in this construction is limited.  Some examples are 'the fact', 'the rumor', 'the suggestion', 'the idea', etc. 
-- Example:  I love the idea [that chimps can talk]. 
*Adjective --- In an adjective complement clause construction the clause occurs after an adjective. 
-- Example:  I am pleased [that George went to the party].

===The Relative Clause===
A relative clause--also called an adjective or adjectival clause--will meet three requirements. First, it will contain a subject and verb. Next, it will begin with a relative pronoun [who, whom, whose, that, or which] or a relative adverb [when, where, or why]. Finally, it will function as an adjective, answering the questions What kind? How many? or Which one? The relative clause will follow one of these two patterns:

 Relative Pronoun [or Relative Adverb]  +  Subject  +  Verb  =   Incomplete Thought  

 Relative Pronoun [Functioning as Subject]  +  Verb  =  Incomplete Thought

===Examples=== 

; Simple sentence
: One independent clause with no subordinate clauses.  It does not contain more than one full sentence pattern.
:: ''Without love, life would be empty.''
: This sentence contains a subject (life), a verb (would be) and 2 types of modifiers (Without love and empty).

; Compound sentence
: Composed of two or more independent clauses with no subordinate clauses.  The two clauses are usually joined by a comma and a conjunction or a semicolon.
:: ''Together we stand, but united we fall.''
: This sentence contains 2 clauses which are joined by &quot;but&quot;.

; Complex sentence
: Composed of one independent clause and one or more subordinate clauses.
:: ''They that sow in tears shall reap in joy.''
: &quot;that sow in tears&quot; is the subordinate clause.

; Compound-complex sentence
: Contains at least two independent clauses and at least one subordinate clause.
:: ''Tell me what you eat, and I will tell you what you are.''
: This sentence contains two independent clauses (one before and one after the comma) and each independent clause contains a subordinate clause (&quot;what you eat&quot; and &quot;what you are&quot;).

==Sentence Purpose==

* '''Declarative sentence''' - used to make a statement
*: ''My dog barks at everything.''

* '''Imperative sentence''' - used to make a request or demand
*: ''Give me that.''

* '''Interrogative sentence''' - used to ask a question
*: ''What are you doing?''

* '''Exclamatory sentence''' - used to make an exclamation
*: ''I don't want that!''

{{BookCat}}</text>
      <sha1>9e7ys0nr66aedrqs5b7mqmjitslrk2l</sha1>
    </revision>
  </page>
  <page>
    <title>English as an Additional Language/The English alphabet</title>
    <ns>0</ns>
    <id>98678</id>
    <revision>
      <id>4657070</id>
      <parentid>4423796</parentid>
      <timestamp>2026-08-10T16:18:44Z</timestamp>
      <contributor>
        <username>Marios727</username>
        <id>3618160</id>
      </contributor>
      <minor />
      <origin>4657070</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1598" sha1="3pudm445b00g6ltr1zen6tzz9yecmmc" xml:space="preserve">{{Info|'''''Note''': If the target audience's native language already uses the Latin alphabet, then much of this information can be omitted.''}}

English is written with the Latin alphabet. It consists of 26 letters:

'''''Lower-case letters'':'''  &lt;nowiki&gt;&lt;span class=&quot;iumb-message&quot; style=&quot;color:orange&quot;&gt; a b c d e f g h i j k l m n o p q r s t u v w x y z&lt;/nowiki&gt;

'''''Upper-case letters'':'''  &lt;nowiki&gt;&lt;span class=&quot;iumb-message&quot; style=&quot;color:blue&quot;&gt; A B C D E F G H I J K L M N O P Q R S T U V W X Y Z&lt;/nowiki&gt;

Each letter has a ''lower-case'' and an ''upper-case'' (or ''capital'') form. In some cases (e.g. the letters S, X, and O), the upper-case form is simply a larger version of the lower-case. However, some letters have differing forms in upper- and lower-case, such as A, Q, and T.

Lower-case letters evolved from modified forms of the upper-case letters, which were used in ancient times.

== Vowels and Consonants ==

There are 5 vowel letters in English: a, e, i, o, u (&quot;y&quot; also acts as a vowel, and are used for orthographic reasons). This does not correlate with the number of vowel sounds, of which there are about 14, depending on dialect.

There are 21 consonant letters: b, c, d, f, g, h, j, k, l, m, n, p, q, r, s, t, v, w, x, y, z.

In many cases, the spelling of an English word only gives a rough indication of its pronunciation. For this reason, the English spelling system is notorious for being one of the hardest to learn of all the alphabetic scripts.

{{audio | English alphabet woman.oga | click here}} to listen to the pronunciation of the alphabet.

{{BookCat}}</text>
      <sha1>3pudm445b00g6ltr1zen6tzz9yecmmc</sha1>
    </revision>
    <revision>
      <id>4657071</id>
      <parentid>4657070</parentid>
      <timestamp>2026-08-10T16:19:37Z</timestamp>
      <contributor>
        <username>Marios727</username>
        <id>3618160</id>
      </contributor>
      <minor />
      <origin>4657071</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1562" sha1="7t06zlf3pr2oced5yrsj5xvopj8nuoy" xml:space="preserve">{{Info|'''''Note''': If the target audience's native language already uses the Latin alphabet, then much of this information can be omitted.''}}

English is written with the Latin alphabet. It consists of 26 letters:

'''''Lower-case letters'':''' &lt;span class=&quot;iumb-message&quot; style=&quot;color:orange&quot;&gt; a b c d e f g h i j k l m n o p q r s t u v w x y z

'''''Upper-case letters'':''' &lt;span class=&quot;iumb-message&quot; style=&quot;color:blue&quot;&gt;
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Each letter has a ''lower-case'' and an ''upper-case'' (or ''capital'') form. In some cases (e.g. the letters S, X, and O), the upper-case form is simply a larger version of the lower-case. However, some letters have differing forms in upper- and lower-case, such as A, Q, and T.

Lower-case letters evolved from modified forms of the upper-case letters, which were used in ancient times.

== Vowels and Consonants ==

There are 5 vowel letters in English: a, e, i, o, u (&quot;y&quot; also acts as a vowel, and are used for orthographic reasons). This does not correlate with the number of vowel sounds, of which there are about 14, depending on dialect.

There are 21 consonant letters: b, c, d, f, g, h, j, k, l, m, n, p, q, r, s, t, v, w, x, y, z.

In many cases, the spelling of an English word only gives a rough indication of its pronunciation. For this reason, the English spelling system is notorious for being one of the hardest to learn of all the alphabetic scripts.

{{audio | English alphabet woman.oga | click here}} to listen to the pronunciation of the alphabet.

{{BookCat}}</text>
      <sha1>7t06zlf3pr2oced5yrsj5xvopj8nuoy</sha1>
    </revision>
    <revision>
      <id>4657131</id>
      <parentid>4657071</parentid>
      <timestamp>2026-08-11T07:21:49Z</timestamp>
      <contributor>
        <username>ShakespeareFan00</username>
        <id>46022</id>
      </contributor>
      <minor />
      <origin>4657131</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1573" sha1="gtjj47u8w7au33otigngzkwt37fqj3y" xml:space="preserve">{{Info|'''''Note''': If the target audience's native language already uses the Latin alphabet, then much of this information can be omitted.''}}

English is written with the Latin alphabet. It consists of 26 letters:

'''''Lower-case letters'':''' &lt;span class=&quot;iumb-message&quot; style=&quot;color:orange&quot;&gt; a b c d e f g h i j k l m n o p q r s t u v w x y z&lt;span&gt;

'''''Upper-case letters'':''' &lt;span class=&quot;iumb-message&quot; style=&quot;color:blue&quot;&gt;A B C D E F G H I J K L M N O P Q R S T U V W X Y Z&lt;span&gt;

Each letter has a ''lower-case'' and an ''upper-case'' (or ''capital'') form. In some cases (e.g. the letters S, X, and O), the upper-case form is simply a larger version of the lower-case. However, some letters have differing forms in upper- and lower-case, such as A, Q, and T.

Lower-case letters evolved from modified forms of the upper-case letters, which were used in ancient times.

== Vowels and Consonants ==

There are 5 vowel letters in English: a, e, i, o, u (&quot;y&quot; also acts as a vowel, and are used for orthographic reasons). This does not correlate with the number of vowel sounds, of which there are about 14, depending on dialect.

There are 21 consonant letters: b, c, d, f, g, h, j, k, l, m, n, p, q, r, s, t, v, w, x, y, z.

In many cases, the spelling of an English word only gives a rough indication of its pronunciation. For this reason, the English spelling system is notorious for being one of the hardest to learn of all the alphabetic scripts.

{{audio | English alphabet woman.oga | click here}} to listen to the pronunciation of the alphabet.

{{BookCat}}</text>
      <sha1>gtjj47u8w7au33otigngzkwt37fqj3y</sha1>
    </revision>
    <revision>
      <id>4657132</id>
      <parentid>4657131</parentid>
      <timestamp>2026-08-11T07:22:31Z</timestamp>
      <contributor>
        <username>ShakespeareFan00</username>
        <id>46022</id>
      </contributor>
      <minor />
      <origin>4657132</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1577" sha1="nrptsgzp8w5ml4dc5nrvei27umee0ki" xml:space="preserve">{{Info|'''''Note''': If the target audience's native language already uses the Latin alphabet, then much of this information can be omitted.''}}

English is written with the Latin alphabet. It consists of 26 letters:

'''''Lower-case letters'':''' 
&lt;span class=&quot;iumb-message&quot; style=&quot;color:orange&quot;&gt; a b c d e f g h i j k l m n o p q r s t u v w x y z&lt;/span&gt;

'''''Upper-case letters'':''' 
&lt;span class=&quot;iumb-message&quot; style=&quot;color:blue&quot;&gt;A B C D E F G H I J K L M N O P Q R S T U V W X Y Z&lt;/span&gt;

Each letter has a ''lower-case'' and an ''upper-case'' (or ''capital'') form. In some cases (e.g. the letters S, X, and O), the upper-case form is simply a larger version of the lower-case. However, some letters have differing forms in upper- and lower-case, such as A, Q, and T.

Lower-case letters evolved from modified forms of the upper-case letters, which were used in ancient times.

== Vowels and Consonants ==

There are 5 vowel letters in English: a, e, i, o, u (&quot;y&quot; also acts as a vowel, and are used for orthographic reasons). This does not correlate with the number of vowel sounds, of which there are about 14, depending on dialect.

There are 21 consonant letters: b, c, d, f, g, h, j, k, l, m, n, p, q, r, s, t, v, w, x, y, z.

In many cases, the spelling of an English word only gives a rough indication of its pronunciation. For this reason, the English spelling system is notorious for being one of the hardest to learn of all the alphabetic scripts.

{{audio | English alphabet woman.oga | click here}} to listen to the pronunciation of the alphabet.

{{BookCat}}</text>
      <sha1>nrptsgzp8w5ml4dc5nrvei27umee0ki</sha1>
    </revision>
  </page>
  <page>
    <title>Solar System/Saturn</title>
    <ns>0</ns>
    <id>100132</id>
    <revision>
      <id>4657103</id>
      <parentid>3957101</parentid>
      <timestamp>2026-08-10T20:28:34Z</timestamp>
      <contributor>
        <username>Plan8-63</username>
        <id>3620551</id>
      </contributor>
      <comment>Not accurate. (Habitable is subjective, and the sun will already have turned into a white dwarfs by 4.5 Billion Years)</comment>
      <origin>4657103</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2940" sha1="42iu6wf69oxy6cq8c8yzdwd3xif04uc" xml:space="preserve">[[File:Saturn during Equinox.jpg|thumb|Natural color photograph of Saturn.]]
Saturn is the sixth planet from the Sun and is the second largest planet (after Jupiter), with a diameter of 120536 kilometers (9.4 times that of 
Earth).  Saturn is known for its spectacular rings, which can be clearly seen with a home telescope of modest size.  Saturn is one of the four gas giants.  Even though Saturn is much more massive than Earth, if it had a solid surface and you stood on it you would weigh only 6% more than you do on Earth.  This is because you would be standing much farther from the center of the planet than you do on Earth. 

==Orbit==

Saturn orbits the Sun in 29.46 Earth-years, with an orbital eccentricity of 0.05 and an average distance from the Sun of 9.54 AU (Earth-Sun distances).

==Rotation==

Saturn rotates prograde (in the direction of its path around the Sun) once every 10 hours 14 minutes, with an axial tilt of 25.33°.

==Physical characteristics==

Saturn is the only planet that is less dense than water—in fact its density is just 0.69 that of water.

==Regions==

==Atmosphere==

===Clouds and winds===

===Spots===

===Vortices===

==Internal structure==
[[File:Saturn diagram.svg|thumb|Diagram of Saturn.]]

==Magnetic field==

===Magnetosphere===

==Rings==
{{clear}}
[[File:Saturn's rings dark side mosaic.jpg|thumb|800px|center|The rings of Saturn.]]
[[File:PIA17172 Saturn eclipse mosaic bright crop.jpg|thumb|Rings of Saturn.]]
===The most beautiful planetary system===

===The discovery Of Saturn's rings===

===Composition of the rings===

===The origin of the rings===

===The shepherd satellites===

===&quot;Spokes&quot; or radial formations===

==Satellites==

===Titan===

Titan is the second largest moon in the solar system and has a diameter over 5% greater than that of the planet Mercury.  It is the only planetary moon that has a thick atmosphere made of nitrogen. Titan has lakes made of liquid methane.

&lt;gallery mode=&quot;packed&quot;&gt;
File:Titan in true color.jpg|Titan in true color.
File:Titan-Complex 'Anti-greenhouse'.jpg|Haze from the atmosphere of Titan.
File:Huygens surface color sr.jpg|Image from the surface of Titan, taken by the probe ''Huygens''.
File:Titan poster.svg|Diagram of Titan.
&lt;/gallery&gt;

===Mimas===
&lt;gallery mode=&quot;packed&quot;&gt;
File:Mimas Cassini.jpg|Mimas
File:Color Near Herschel Crater.jpg|Crater on Mimas
&lt;/gallery&gt;

===Enceladus===
&lt;gallery mode=&quot;packed&quot; heights=&quot;200&quot;&gt;
File:PIA17202 - Approaching Enceladus.jpg|Enceladus
File:PIA08409 North Polar Region of Enceladus.jpg|Close up
File:PIA17204-SaturnMoon-Enceladus-UpClose-20151028.jpg|Terrain close up
File:Fountains of Enceladus PIA07758.jpg|Plumes of Enceladus
File:Enceladus orbit 2.jpg|Orbit of Enceladus
&lt;/gallery&gt;

===Tethys===
&lt;gallery mode=&quot;packed&quot; heights=&quot;200&quot;&gt;
File:PIA18317-SaturnMoon-Tethys-Cassini-20150411.jpg|Tethys
&lt;/gallery&gt;

===Dione===

===Rhea===

===Iapetus===

===Hyperion===

===Phoebe===

{{BookCat}}</text>
      <sha1>42iu6wf69oxy6cq8c8yzdwd3xif04uc</sha1>
    </revision>
    <revision>
      <id>4657104</id>
      <parentid>4657103</parentid>
      <timestamp>2026-08-10T20:32:48Z</timestamp>
      <contributor>
        <username>Plan8-63</username>
        <id>3620551</id>
      </contributor>
      <comment>/* Enceladus */ Added information for Mimas and Enceladus</comment>
      <origin>4657104</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3341" sha1="ba0a8sx3jizb8ctvulx35onav7iccaw" xml:space="preserve">[[File:Saturn during Equinox.jpg|thumb|Natural color photograph of Saturn.]]
Saturn is the sixth planet from the Sun and is the second largest planet (after Jupiter), with a diameter of 120536 kilometers (9.4 times that of 
Earth).  Saturn is known for its spectacular rings, which can be clearly seen with a home telescope of modest size.  Saturn is one of the four gas giants.  Even though Saturn is much more massive than Earth, if it had a solid surface and you stood on it you would weigh only 6% more than you do on Earth.  This is because you would be standing much farther from the center of the planet than you do on Earth. 

==Orbit==

Saturn orbits the Sun in 29.46 Earth-years, with an orbital eccentricity of 0.05 and an average distance from the Sun of 9.54 AU (Earth-Sun distances).

==Rotation==

Saturn rotates prograde (in the direction of its path around the Sun) once every 10 hours 14 minutes, with an axial tilt of 25.33°.

==Physical characteristics==

Saturn is the only planet that is less dense than water—in fact its density is just 0.69 that of water.

==Regions==

==Atmosphere==

===Clouds and winds===

===Spots===

===Vortices===

==Internal structure==
[[File:Saturn diagram.svg|thumb|Diagram of Saturn.]]

==Magnetic field==

===Magnetosphere===

==Rings==
{{clear}}
[[File:Saturn's rings dark side mosaic.jpg|thumb|800px|center|The rings of Saturn.]]
[[File:PIA17172 Saturn eclipse mosaic bright crop.jpg|thumb|Rings of Saturn.]]
===The most beautiful planetary system===

===The discovery Of Saturn's rings===

===Composition of the rings===

===The origin of the rings===

===The shepherd satellites===

===&quot;Spokes&quot; or radial formations===

==Satellites==

===Titan===

Titan is the second largest moon in the solar system and has a diameter over 5% greater than that of the planet Mercury.  It is the only planetary moon that has a thick atmosphere made of nitrogen. Titan has lakes made of liquid methane.

&lt;gallery mode=&quot;packed&quot;&gt;
File:Titan in true color.jpg|Titan in true color.
File:Titan-Complex 'Anti-greenhouse'.jpg|Haze from the atmosphere of Titan.
File:Huygens surface color sr.jpg|Image from the surface of Titan, taken by the probe ''Huygens''.
File:Titan poster.svg|Diagram of Titan.
&lt;/gallery&gt;

===Mimas===
Mimas is a tiny, yet spherical moon of Saturn. In fact, Mimas is the smallest spherical body in the Solar System.The moon is dominated by Herschel, a large crater on its surface.&lt;gallery mode=&quot;packed&quot;&gt;
File:Mimas Cassini.jpg|Mimas
File:Color Near Herschel Crater.jpg|Crater on Mimas
&lt;/gallery&gt;

===Enceladus===
Enceladus is a small moon of Saturn accentuated by its icy surface. It is believed that it hosts a large subsurface ocean, possibly capable of being friendly to life. Enceladus also has numerous geysers near its south pole.&lt;gallery mode=&quot;packed&quot; heights=&quot;200&quot;&gt;
File:PIA17202 - Approaching Enceladus.jpg|Enceladus
File:PIA08409 North Polar Region of Enceladus.jpg|Close up
File:PIA17204-SaturnMoon-Enceladus-UpClose-20151028.jpg|Terrain close up
File:Fountains of Enceladus PIA07758.jpg|Plumes of Enceladus
File:Enceladus orbit 2.jpg|Orbit of Enceladus
&lt;/gallery&gt;

===Tethys===
&lt;gallery mode=&quot;packed&quot; heights=&quot;200&quot;&gt;
File:PIA18317-SaturnMoon-Tethys-Cassini-20150411.jpg|Tethys
&lt;/gallery&gt;

===Dione===

===Rhea===

===Iapetus===

===Hyperion===

===Phoebe===

{{BookCat}}</text>
      <sha1>ba0a8sx3jizb8ctvulx35onav7iccaw</sha1>
    </revision>
  </page>
  <page>
    <title>Wikibooks:Reading room/General</title>
    <ns>4</ns>
    <id>112405</id>
    <revision>
      <id>4657130</id>
      <parentid>4656736</parentid>
      <timestamp>2026-08-11T07:21:07Z</timestamp>
      <contributor>
        <username>ShakespeareFan00</username>
        <id>46022</id>
      </contributor>
      <minor />
      <origin>4657130</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="14767" sha1="dao68cpq7zhkfbwdpoyzytewqxn94oq" xml:space="preserve">__NEWSECTIONLINK__ {{Discussion Rooms}} {{Shortcut|WB:CHAT|WB:RR/G|WB:GENERAL}} {{TOC left|limit=3}}
{{User:MiszaBot/config
|archive = Wikibooks:Reading room/Archives/%(year)d/%(monthname)s
|algo = old(60d)
|counter = 1
|minthreadstoarchive = 1
|minthreadsleft = 1
|key = 7a0ac23cf8049e4d9ff70cabb5649d1a
}}
Welcome to the '''General reading room'''. On this page, Wikibookians are free to talk about the Wikibooks project in general. For proposals for improving Wikibooks, see the [[../Proposals/]] reading room.
{{clear}}

[[Category:Reading room]]

== June 2026 Wikimedia Café meetups regarding the English Wikipedia Editor Reflections project ==

&lt;div class=&quot;border-box&quot; style=&quot;background-color: var(--background-color-warning-subtle, #f8eaba); max-width: 875px; padding: 5px; border: 1px solid black; margin: 5px; color: var(--clr-dark)&quot;&gt;
&lt;div class=&quot;box&quot; style=&quot;float:left; padding-top: 10px; padding-right: 10px; padding-left: 10px; padding-bottom: 10px;&quot;&gt;[[File:Wikimedia Café logo in plain SVG format.svg|60px|alt=The logo for the Wikimedia Café]]&lt;/div&gt;
Hello! There will be two '''[https://meta.wikimedia.org/wiki/Wikimedia_Caf%C3%A9 Wikimedia Café]''' discussion opportunities during the last weekend of June. Both sessions will focus on the [https://en.wikipedia.org/wiki/Wikipedia:Editor_reflections English Wikipedia Editor Reflections project]. The featured guest in the Café will be [https://en.wikipedia.org/wiki/User:Clovermoss User:Clovermoss]. Participants may attend either or both sessions.

#'''27 June 2026 15:00 UTC''' ([https://zonestamp.toolforge.org/1782572400 timestamp converter]), at a time friendly to the Americas, Africa, and Europe
#'''28 June 2026 03:00 UTC''' ([https://zonestamp.toolforge.org/1782615600 timestamp converter]), at a time friendly to Asia and the Pacific

Please see the Café page for more information, including [https://meta.wikimedia.org/wiki/Wikimedia_Caf%C3%A9#How_to_attend_the_session how to register]!
&lt;br /&gt;
[[File:Buntstifte Eberhard Faber crop 64h.jpg|860px|alt=cropped image of colored pencils]]&lt;/div&gt;
&lt;span style=&quot;white-space:nowrap;&quot;&gt;[[User:Pine|&lt;span style=&quot;color:#01796f; text-shadow:#00BFFF 0 0 1.0em&quot;&gt;↠Pine&lt;/span&gt;]] [[User talk:Pine|&lt;span style=&quot;color:DeepSkyBlue&quot;&gt;(&lt;b style=&quot;color:#FFDF00;text-shadow:#FFDF00 0 0 1.0em&quot;&gt;✉&lt;/b&gt;)&lt;/span&gt;]]&lt;/span&gt; 04:09, 15 June 2026 (UTC)

== Images lost in Engineering Acoustics ==

Hello,

I just made an updated PDF version of the wiki book on Engineering Acoustics.
During this processes I realized that 19 Images are missing. I left the respective chapters out of the PDF version. You can find the missing files by opening https://en.wikibooks.org/wiki/Engineering_Acoustics/Print_version in your web browser and search for the text File: . I am not sure why they were deleted. But possibly they were moved to Wikimedia Commons first and deleted after that. I could try to restore the from the 16 years old PDF version but I lack any authorship information so I think we need to redraw all of them. Furthermore I realized that some of the rest of the images in the wiki book have got a very poor resolution

Yours 18:22, 18 June 2026 (UTC) [[User:Dirk Hünniger|Dirk Hünniger]] ([[User talk:Dirk Hünniger|discuss]] • [[Special:Contributions/Dirk Hünniger|contribs]]) 18:22, 18 June 2026 (UTC)
: {{re|Dirk Hünniger}} All media ([[:File: Acousticplanewave1.gif|A]][[:File: Acousticcontrolsurface.gif|B]][[:File: Acousticcontrolsurface.gif|C]][[:File: Acousticpressure1.gif|D]][[:File: Ra analogs.png|E]][[:File: Acoustic gen.png|F]][[:File: Enclosed Piston.png|G]][[:File: Equ1.jpg|H]][[:File: Equ3.gif|I]][[:File: Equ4.gif|K]][[:File: Comp.gif|L]][[:File: Example2holm1sol.JPG|M]][[:File: Exam2prob.JPG|N]][[:File: Exam2sol.JPG|O]][[:File: 1Dwave graph1.png|P]][[:File: String dwg.jpg|Q]][[:File: Equations1.jpg|R]][[:File: Equations2.jpg|S]]) except [[:File: Inductive law pass filter.jpg|Inductive law pass filter.jpg]] and [[:File: Open-twister.gif|Open-twister.gif]] were once deleted by [[User: Jguk|Jguk]] and [[User: Darklama|Darklame]] because after a grace period they still lacked copyright information. ‑‑[[User:Kai Burghardt|Kai Burghardt]] ([[User talk:Kai Burghardt|discuss]] • [[Special:Contributions/Kai Burghardt|contribs]]) 14:51, 10 July 2026 (UTC)
::@[[User:Kai Burghardt|Kai Burghardt]]
::Do we also need to delete the PDF then? It contains theses images.
::Yours [[User:Dirk Hünniger|Dirk Hünniger]] ([[User talk:Dirk Hünniger|discuss]] • [[Special:Contributions/Dirk Hünniger|contribs]]) 07:49, 11 July 2026 (UTC)
::: {{re|Dirk Hünniger}} It depends on the images’ contents, whether they’re copyrightable. ‑‑[[User:Kai Burghardt|Kai Burghardt]] ([[User talk:Kai Burghardt|discuss]] • [[Special:Contributions/Kai Burghardt|contribs]]) 08:40, 11 July 2026 (UTC)
::::@[[User:Kai Burghardt|Kai Burghardt]] Well to me the look copyrightable. And further more its just the same images that were deleted from the wiki due to copyright issues [[User:Dirk Hünniger|Dirk Hünniger]] ([[User talk:Dirk Hünniger|discuss]] • [[Special:Contributions/Dirk Hünniger|contribs]]) 13:33, 11 July 2026 (UTC)
::::: {{re|Dirk Hünniger}} As far as I understand the issue was a formality. All files must bear license info, regardless whether they’re copyrightable or not. It is quite possible all deleted images don’t meet the threshold of originality, but still were deleted because of this formality. Images like [[:File: Equ1.jpg|File: Equ1.jpg]] ''presumably'' contain ''just'' some rasterized text formula and as such are not copyrightable. I have not had a look at them, so I can’t tell. ‑‑[[User:Kai Burghardt|Kai Burghardt]] ([[User talk:Kai Burghardt|discuss]] • [[Special:Contributions/Kai Burghardt|contribs]]) 14:30, 11 July 2026 (UTC)
:::::: @[[User:Kai Burghardt|Kai Burghardt]] If its just a formality and the images don't meet the threshold to be copyrightable we could just restore the deleted images from the PDF. But keeping the PDF and not restoring the images surely is a contradiction. Furthermore there are quite a lot of books with the same problem. [[User:Dirk Hünniger|Dirk Hünniger]] ([[User talk:Dirk Hünniger|discuss]] • [[Special:Contributions/Dirk Hünniger|contribs]]) 17:25, 11 July 2026 (UTC)

== Citing WikiBooks? ==

Wikipedia has a page for Citing Wikipedia, but I haven't found one here, so I have a few questions:

# How would I cite Wikibooks in an essay?
# Do I need to cite sources on Wikibooks? If so, how?

[[User:BlazeFlames|BlazeFlames]] ([[User talk:BlazeFlames|discuss]] • [[Special:Contributions/BlazeFlames|contribs]]) 22:48, 18 June 2026 (UTC)

:# This should give you a good method: https://www.scribbr.com/citing-sources/how-to-cite-wikipedia/
:# Generally, no. We have [[Wikibooks:Policies and guidelines|no policy that requires or prohibits citing sources]] and we have a [[Help:Editing#References|help page on how to do it]], with a [[Wikibooks:Templates/Sources|number of templates]] to standardize the process. There is definitely value in citing sources, so I don't want to discourage it.
:―[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''&lt;span style=&quot;color:black&quot;&gt;v&lt;/span&gt;f&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 09:10, 19 June 2026 (UTC)
:: {{re|BlazeFlames}} As you can see in [[Special: Version#mw-version-ext|Special: Version § Installed Extensions]] this MediaWiki has the [[mw: Special: MyLanguage/Extension: CiteThisPage|CiteThisPage extension]] installed. On the English‑language edition of Wikibooks you can navigate to [[Special: CiteThisPage/Typewriting|Special: CiteThisPage/…]] even though it is not listed in the [[MediaWiki: Sidebar]] (but it’s listed in [[Special: SpecialPages#mw-specialpagesgroup-pagetools|Special: SpecialPages]]). However, on {{abbr|WB|Wikibooks}} I would link via the [[mw: Special: MyLanguage/Help: Page ID|page ID]] rather than the page title; replace &lt;syntaxhighlight lang='text' inline&gt;title=Booktitle&lt;/syntaxhighlight&gt; with &lt;syntaxhighlight lang='text' inline&gt;curid=123456&lt;/syntaxhighlight&gt;. ‑‑[[User:Kai Burghardt|Kai Burghardt]] ([[User talk:Kai Burghardt|discuss]] • [[Special:Contributions/Kai Burghardt|contribs]]) 15:09, 10 July 2026 (UTC)

== Unhide the FlaggedRevs comment box? ==

:''Reposted from [[Wikibooks:Reading room/Archives/2026/April#Is this CSS code necessary?]] as the former link had no participation.''
I propose unhiding the FlaggedRevs comment box (via MediaWiki:Common.css) because it might be useful to add in a comment when reverting with the FlaggedRevs reversion, unlike rollback. It might also be useful in cases to add a comment on what the user edited when accepting a revision. Thoughts? [[User:Codename Noreste|&lt;span style=&quot;color:#0024FF&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 21:17, 20 June 2026 (UTC)

== RFC about AI-generated content in Wikimedia Commons ==

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt; You are invited to participate in a [[c:Commons:Requests for comment/Policy update for AI content|request for comment on Wikimedia Commons about a policy update for AI content]]. This may affect files that are uploaded to Wikimedia Commons for use on this project. Thank you. [[m:User:Codename Noreste|Codename Noreste]] ([[m:User talk:Codename Noreste|discuss]])&lt;/bdi&gt; 17:11, 23 June 2026 (UTC)
&lt;!-- Message sent by User:Codename Noreste@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery&amp;oldid=30513860 --&gt;

== Deployment of Legal and Safety Contacts Link in the Footer of Your Wiki ==

&lt;section begin=&quot;Message&quot;/&gt;
'''Legal &amp; Safety Contacts'''

Hello community, the Wikimedia Foundation has provided a [[wmf:Special:MyLanguage/Legal:Wikimedia Foundation Legal and Safety Contact Information|single legal and safety contact page]], to be linked in the footer of your wiki, to ensure access to accurate legal information. This is a regulatory requirement. We have already rolled out links to English, German, Italian, Spanish and other wikis and we will deploy to your wiki soon. [[m:Special:MyLanguage/Wikimedia_Foundation_Legal_and_Safety_Contacts_FAQ|Please read more on the project page]] and leave any comments in this thread or on the [[m:Special:MyLanguage/Talk:Wikimedia Foundation Legal and Safety Contacts FAQ|talk page]].

&lt;section end=&quot;Message&quot;/&gt;

-- [[User:Sannita (WMF)|User:Sannita (WMF)]] ([[User talk:Sannita (WMF)|talk]]) 13:30, 25 June 2026 (UTC)
&lt;!-- Message sent by User:Sannita (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=User:Sannita_(WMF)/Mass_sending_test&amp;oldid=30731267 --&gt;

== A question about the user right move-subpages ==

Even though reviewers have the ability to move 100 pages per minute (per InitialiseSettings.php), they do not have &lt;code&gt;move-subpages&lt;/code&gt;, which allows moving a book (with all its subpages) in one single action. Is this user right considered sensitive (hence it is restricted to administrators by default)? [[User:Codename Noreste|&lt;span style=&quot;color:#0024FF&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 04:23, 9 July 2026 (UTC)

:I'm not 100% sure what the problem is as long as mass moving is limited to admins in the first place, as this can really cause problems (I recently encountered this mass-moving 100 out of c. 260 pages on a wiki). I support filing a ticket at [[:phab:]] to extend [[:mw:Manual:$wgMaximumMovedPages|$wgMaximumMovedPages]] to 1,000. ―[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''&lt;span style=&quot;color:black&quot;&gt;v&lt;/span&gt;f&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 05:33, 9 July 2026 (UTC)

== July 2026 Wikimedia Café meetups regarding Wikimedia governance and options for reform ==

&lt;div class=&quot;border-box&quot; style=&quot;background-color: var(--background-color-warning-subtle, #f8eaba); max-width: 875px; padding: 5px; border: 1px solid black; margin: 5px; color: var(--clr-dark)&quot;&gt;
&lt;div class=&quot;box&quot; style=&quot;float:left; padding-top: 10px; padding-right: 10px; padding-left: 10px; padding-bottom: 10px;&quot;&gt;[[File:Wikimedia Café logo in plain SVG format.svg|60px|alt=The logo for the Wikimedia Café]]&lt;/div&gt;
Hello! There will be two '''[https://meta.wikimedia.org/wiki/Wikimedia_Caf%C3%A9 Wikimedia Café]''' discussion opportunities in July. Both sessions will focus on Wikimedia governance, including possible follow-ups to the [https://meta.wikimedia.org/wiki/Movement_Charter Movement Charter] and options for reform. Participants may attend either or both Café sessions. 

This month, to deconflict the Café meetups from Wikimania, the meetups will be held one day later than usual.

#'''26 July 2026 15:00 UTC''' ([https://zonestamp.toolforge.org/1785078000 timestamp converter]), at a time friendly to the Americas, Africa, and Europe
#'''27 July 2026 03:00 UTC''' ([https://zonestamp.toolforge.org/1785121200 timestamp converter]), at a time friendly to Asia and the Pacific

Please see the Café page for more information, including [https://meta.wikimedia.org/wiki/Wikimedia_Caf%C3%A9#How_to_attend_the_session how to register]!
&lt;br /&gt;
[[File:Buntstifte Eberhard Faber crop 64h.jpg|860px|alt=cropped image of colored pencils]]&lt;/div&gt;
&lt;span style=&quot;white-space:nowrap;&quot;&gt;[[User:Pine|&lt;span style=&quot;color:#01796f; text-shadow:#00BFFF 0 0 1.0em&quot;&gt;↠Pine&lt;/span&gt;]] [[User talk:Pine|&lt;span style=&quot;color:DeepSkyBlue&quot;&gt;(&lt;b style=&quot;color:#FFDF00;text-shadow:#FFDF00 0 0 1.0em&quot;&gt;✉&lt;/b&gt;)&lt;/span&gt;]]&lt;/span&gt; 03:53, 13 July 2026 (UTC)

== Request for comment (the future of Abstract Wikipedia) ==

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;You are invited to voice your opinions in a [[:m:Requests for comment/The future of Abstract Wikipedia|request for comment about the future of Abstract Wikipedia]]. {{Int:Feedback-thanks-title}} [[:m:User:Kowal2701|Kowal2701]] ([[:m:User talk:Kowal2701|talk]])  12:24, 24 July 2026 (UTC)&lt;/bdi&gt;
&lt;!-- Message sent by User:DreamRimmer@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery&amp;oldid=30513860 --&gt;

== Call for administrators ==

Any experienced editor who has a good understanding of Wikibooks' policies should consider applying for administrator permissions at [[Wikibooks:Requests for permissions]]. Thank you. [[User:Codename Noreste|&lt;span style=&quot;color: blue&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 22:10, 5 August 2026 (UTC)</text>
      <sha1>dao68cpq7zhkfbwdpoyzytewqxn94oq</sha1>
    </revision>
  </page>
  <page>
    <title>Wikibooks:Reading room/Technical Assistance</title>
    <ns>4</ns>
    <id>112409</id>
    <revision>
      <id>4657143</id>
      <parentid>4654892</parentid>
      <timestamp>2026-08-11T08:10:28Z</timestamp>
      <contributor>
        <username>ArchiverBot</username>
        <id>1227662</id>
      </contributor>
      <minor />
      <comment>Bot: Archiving 2 threads (older than 50 days) to [[Wikibooks:Reading room/Archives/2026/June]]</comment>
      <origin>4657143</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="4770" sha1="eme36b2dqk88mhf26j9ze19jzo4586x" xml:space="preserve">__NEWSECTIONLINK__ {{Discussion Rooms}} {{Shortcut|WB:TECH}} {{TOC left}}
{{User:MiszaBot/config
|archive = Wikibooks:Reading room/Archives/%(year)d/%(monthname)s
|algo = old(50d)
|counter = 1
|minthreadstoarchive = 1
|key = bf05448a5bbfa2d2a4efbdad870e68a4
|minthreadsleft = 1
}}
Welcome to the '''Technical Assistance reading room'''. Get assistance on questions related to [[w:MediaWiki|MediaWiki]] markup, CSS, JavaScript, and such as they relate to Wikibooks. '''This is not a general-purpose technical support room'''.

To submit a ''bug notice or feature request'' for the MediaWiki software, visit [[phabricator:|Phabricator]].

To get more information about the ''MediaWiki software'', or to download your own copy, visit [[mw:|MediaWiki]]

There are also two IRC channels for technical help: {{Channel|mediawiki}} for issues about the software, and {{channel|mediawiki-core}} for [[m:WMF|WMF]] server or configuration issues.
{{clear}}
[[Category:Reading room]]

== Viewing unreviewed changes, and recent changes, for a particular book ==

I've recently started editing [[Chess Opening Theory]] after a long hiatus. Two things
* How can I view recent edits, for this book alone. I'm aware of [[Using_Wikibooks/How_To_Edit_A_Wikibook#Watching All Pages in a Book|Watching All Pages in a Book]], which was well hidden on the page on editing, rather than on tracking changes (since rectified), but the advice there is unhelpful. Option 1 is entirely impractical, as one cannot add hundreds of pages one does not know about, and Option 2 simply doesn't work. For example, at this moment, there are 12 relevant edits listed in the main [[Special:RecentChanges]] page (which goes back to 9 July), but the suggested [https://en.wikibooks.org/wiki/Special:RecentChangesLinked/Chess_Opening_Theory Related Changes] only lists pages directly linked from the top level.
* Similarly, how can one see the unreviewed changes for this book (or even all the books, where I can at least manually filter). I noticed a whole lot going back more than a month and approved most of them, but this was only through some tedious digging around through user contributions and page histories.
**Partially answering this question myself, there's [https://en.wikibooks.org/w/index.php?title=Special%3APendingChanges&amp;namespace=&amp;tagFilter=&amp;limit=50&amp;category=&amp;size= this page]. Which brings up a followup question. My contributions page doesn't list the changes I've approved (only the one I declined). Is there a way to see these? [[User:Greenman|Greenman]] ([[User talk:Greenman|discuss]] • [[Special:Contributions/Greenman|contribs]]) 21:38, 13 July 2026 (UTC)
Thanks! [[User:Greenman|Greenman]] ([[User talk:Greenman|discuss]] • [[Special:Contributions/Greenman|contribs]]) 21:29, 13 July 2026 (UTC)

:At the risk of sounding pedantic, a hack for the first problem whereby [[Special:RecentChangesLinked/Chess_Opening_Theory]] only shows changes that are linked to the top page of the book directly and not all sub-pages or sub-sub-sub-pages, etc. is to just make them all linked from the top page. This can be done with a template that may make it a little more pretty or discreet than a huge list of links. ―[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''&lt;span style=&quot;color:black&quot;&gt;v&lt;/span&gt;f&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 00:53, 14 July 2026 (UTC)
::Thanks, but this doesn't really help. Besides having to add thousands of links to the front page, which certainly shouldn't be displayed there, when someone adds a new variation (which is what a large portion of the edits are), the new entry won't appear on Recent Changes until specifically linked from the front page. [[User:Greenman|Greenman]] ([[User talk:Greenman|discuss]] • [[Special:Contributions/Greenman|contribs]]) 17:23, 15 July 2026 (UTC)
:@[[User:Greenman|Greenman]] I think using the book categories at [[Special:UnreviewedPages]] might be helpful here—is [https://en.wikibooks.org/w/index.php?title=Special%3AUnreviewedPages&amp;namespace=0&amp;category=Book%3AChess+Opening+Theory this] approximately what you're looking for? —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 18:24, 16 July 2026 (UTC)
::@[[User:Greenman|Greenman]] I think you're also looking for [[Special:Log/review]]. Cheers —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 18:32, 16 July 2026 (UTC)
:::Thanks, those are helpful. [[User:Greenman|Greenman]] ([[User talk:Greenman|discuss]] • [[Special:Contributions/Greenman|contribs]]) 15:04, 18 July 2026 (UTC)</text>
      <sha1>eme36b2dqk88mhf26j9ze19jzo4586x</sha1>
    </revision>
  </page>
  <page>
    <title>Chess Opening Theory/1. e4/1...Nf6/2. e5/2...Nd5/3. c4/3...Nb6</title>
    <ns>0</ns>
    <id>125622</id>
    <revision>
      <id>4657156</id>
      <parentid>4655126</parentid>
      <timestamp>2026-08-11T11:23:07Z</timestamp>
      <contributor>
        <username>JCrue</username>
        <id>2226064</id>
      </contributor>
      <minor />
      <origin>4657156</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1635" sha1="s1tcxm22l52ot332fhdz8r1r6lwm2i4" xml:space="preserve">{{Chess Opening Theory/Position
|name=Two pawns attack
|eco=[[Chess/ECOB|B02]]
|parent=[[Chess Opening Theory/1. e4/1...Nf6|Alekhine's defence]] → [[Chess Opening Theory/1. e4/1...Nf6/2. e5/2...Nd5/3. c4|Two pawns attack]]
}}
== 3...Nb6 ==

White may now play [[/4. d4|'''4. d4''']] to sure up their centre. This is the main move and reaches positions familiar from the 3. d4 move order, where often White plays c4 as well. 4...d6 5. exd6 [[Chess Opening Theory/1. e4/1...Nf6/2. e5/2...Nd5/3. d4/3...d6/4. c4/4...Nb6/5. exd6|reaches the exchange variation]]; 4...d6 5. f4 transposes into the [[Chess Opening Theory/1. e4/1...Nf6/2. e5/2...Nd5/3. d4/3...d6/4. c4/4...Nb6/5. f4|four pawns attack]]. 

[[/4. c5|'''4. c5''']] stays in original territory. This is the '''Lasker variation'''. White chases the knight again but it usually returns to plant itself on the newly minted outpost on d5, 4...Nd5. 5. Nc3 e6 6. Nxd5 exd5 7. d4 to close up the outpost might be sensible, or the game may continue 4...Nd5 5. Bc4 e6 6. d4 b6 7. cxb6 axb6 =.

[[/4. b3|'''4. b3''']] is the '''Steiner variation'''.

[[/4. a4|'''4. a4''']] is the '''Tate variation'''.

==Theory table==
{{ChessTable}}

'1.e4 Nf6 2.e5 Nd5 3.c4 Nb6'
&lt;table border=&quot;0&quot; cellspacing=&quot;0&quot; cellpadding=&quot;4&quot;&gt;
	&lt;tr&gt;
		&lt;th&gt;&lt;/th&gt;
		&lt;th align=&quot;left&quot;&gt;4&lt;/th&gt;
	&lt;/tr&gt;
	&lt;tr&gt;
		&lt;th align=&quot;right&quot;&gt;&amp;nbsp;&lt;/th&gt;
		&lt;td&gt;[[/4. c5|c5]]&lt;br&gt;
		-&lt;/td&gt;
		&lt;td&gt;=&lt;/td&gt;
	&lt;/tr&gt;
	&lt;tr&gt;
		&lt;th align=&quot;right&quot;&gt;&amp;nbsp;&lt;/th&gt;
		&lt;td&gt;[[/4. d4|d4]]&lt;br&gt;
		-&lt;/td&gt;
		&lt;td&gt;=&lt;/td&gt;
	&lt;/tr&gt;
&lt;/table&gt;
{{ChessMid}}
==References==
{{reflist}}
=== See also ===
{{Wikipedia|Alekhine Defence}}
{{BCO2}}
{{Chess Opening Theory/Footer}}</text>
      <sha1>s1tcxm22l52ot332fhdz8r1r6lwm2i4</sha1>
    </revision>
    <revision>
      <id>4657159</id>
      <parentid>4657156</parentid>
      <timestamp>2026-08-11T11:49:07Z</timestamp>
      <contributor>
        <username>JCrue</username>
        <id>2226064</id>
      </contributor>
      <minor />
      <comment>/* 3...Nb6 */</comment>
      <origin>4657159</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1637" sha1="bzhyzw1p7r8dvq2uz8xgtpf94cg60mb" xml:space="preserve">{{Chess Opening Theory/Position
|name=Two pawns attack
|eco=[[Chess/ECOB|B02]]
|parent=[[Chess Opening Theory/1. e4/1...Nf6|Alekhine's defence]] → [[Chess Opening Theory/1. e4/1...Nf6/2. e5/2...Nd5/3. c4|Two pawns attack]]
}}
== 3...Nb6 ==

White may now play [[/4. d4|'''4. d4''']] to sure up their centre. This is the main move and reaches positions familiar from the 3. d4 move order, where often White plays c4 as well. 4...d6 5. exd6 [[Chess Opening Theory/1. e4/1...Nf6/2. e5/2...Nd5/3. d4/3...d6/4. c4/4...Nb6/5. exd6|reaches the exchange variation]]; 4...d6 5. f4 transposes into the [[Chess Opening Theory/1. e4/1...Nf6/2. e5/2...Nd5/3. d4/3...d6/4. c4/4...Nb6/5. f4|four pawns attack]]. 

[[/4. c5|'''4. c5''']] stays in original territory. This is the '''Lasker variation'''. White chases the knight again but it usually returns to plant itself on the newly minted outpost on d5, 4...Nd5. 5. Nc3 e6 6. Nxd5 exd5 7. d4 to close up the outpost might be sensible, or the game may continue 4...Nd5 5. Bc4 e6 6. d4 b6 7. cxb6 axb6 =.

[[/4. b3|'''4. b3''']] is the '''Steiner variation'''.

[[/4. a4|'''4. a4!?''']] is the '''Tate variation'''.

==Theory table==
{{ChessTable}}

'1.e4 Nf6 2.e5 Nd5 3.c4 Nb6'
&lt;table border=&quot;0&quot; cellspacing=&quot;0&quot; cellpadding=&quot;4&quot;&gt;
	&lt;tr&gt;
		&lt;th&gt;&lt;/th&gt;
		&lt;th align=&quot;left&quot;&gt;4&lt;/th&gt;
	&lt;/tr&gt;
	&lt;tr&gt;
		&lt;th align=&quot;right&quot;&gt;&amp;nbsp;&lt;/th&gt;
		&lt;td&gt;[[/4. c5|c5]]&lt;br&gt;
		-&lt;/td&gt;
		&lt;td&gt;=&lt;/td&gt;
	&lt;/tr&gt;
	&lt;tr&gt;
		&lt;th align=&quot;right&quot;&gt;&amp;nbsp;&lt;/th&gt;
		&lt;td&gt;[[/4. d4|d4]]&lt;br&gt;
		-&lt;/td&gt;
		&lt;td&gt;=&lt;/td&gt;
	&lt;/tr&gt;
&lt;/table&gt;
{{ChessMid}}
==References==
{{reflist}}
=== See also ===
{{Wikipedia|Alekhine Defence}}
{{BCO2}}
{{Chess Opening Theory/Footer}}</text>
      <sha1>bzhyzw1p7r8dvq2uz8xgtpf94cg60mb</sha1>
    </revision>
  </page>
  <page>
    <title>Vehicle Identification Numbers (VIN codes)/World Manufacturer Identifier (WMI)</title>
    <ns>0</ns>
    <id>142006</id>
    <revision>
      <id>4657064</id>
      <parentid>4656825</parentid>
      <timestamp>2026-08-10T15:57:42Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <comment>/* List of Many WMIs */</comment>
      <origin>4657064</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="135829" sha1="s5ukhe1ybgxgqk4r7vj5hiczjn5ik2r" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Panyu Hua'Nan Motors Industry Co. Ltd. (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LE8 || Zhejiang Senling Motorcycle Co. Ltd.
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (truck)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-

| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J5 || Big Dog Motorcycles
|-
| 5J5 || Club Car
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Trailers LLC (truck trailer)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51Z || Monaco RV (incomplete vehicle) manufatcured by Navistar RV LLC
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailers (truck trailer)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>s5ukhe1ybgxgqk4r7vj5hiczjn5ik2r</sha1>
    </revision>
    <revision>
      <id>4657067</id>
      <parentid>4657064</parentid>
      <timestamp>2026-08-10T16:05:02Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657067</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="135829" sha1="jzpoy1yjem7swvgmfa4dkphhm2okp1t" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Panyu Hua'Nan Motors Industry Co. Ltd. (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LE8 || Zhejiang Senling Motorcycle Co. Ltd.
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (truck)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-

| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J5 || Big Dog Motorcycles
|-
| 5J5 || Club Car
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Trailers LLC (truck trailer)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51Z || Monaco RV (incomplete vehicle) manufatcured by Navistar RV LLC
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailers (truck trailer)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>jzpoy1yjem7swvgmfa4dkphhm2okp1t</sha1>
    </revision>
    <revision>
      <id>4657069</id>
      <parentid>4657067</parentid>
      <timestamp>2026-08-10T16:15:17Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657069</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="135903" sha1="0md2p6t6s104ibo1vuizyo3hggi6rgo" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Panyu Hua'Nan Motors Industry Co. Ltd. (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LE8 || Guangzhou Huaye Electric Vehicle Technology Co., Ltd. (Formerly Guangzhou Panyu Huanan Motors Group Co., Ltd.)
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (truck)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-

| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J5 || Big Dog Motorcycles
|-
| 5J5 || Club Car
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Trailers LLC (truck trailer)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51Z || Monaco RV (incomplete vehicle) manufatcured by Navistar RV LLC
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailers (truck trailer)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>0md2p6t6s104ibo1vuizyo3hggi6rgo</sha1>
    </revision>
    <revision>
      <id>4657077</id>
      <parentid>4657069</parentid>
      <timestamp>2026-08-10T16:35:42Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657077</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="135884" sha1="gpcqazdtfn2dnob8yq07hnmy86pzah2" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Huaye Electric Vehicle Technology Co., Ltd. (Formerly Guangzhou Panyu Huanan Motors Group Co., Ltd.) (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (truck)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 18X || Western Recreational Vehicles
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-

| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J5 || Big Dog Motorcycles
|-
| 5J5 || Club Car
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Trailers LLC (truck trailer)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51Z || Monaco RV (incomplete vehicle) manufatcured by Navistar RV LLC
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailers (truck trailer)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>gpcqazdtfn2dnob8yq07hnmy86pzah2</sha1>
    </revision>
    <revision>
      <id>4657079</id>
      <parentid>4657077</parentid>
      <timestamp>2026-08-10T16:41:15Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657079</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="135903" sha1="dbhyckicxf6ex60n8r6sfreseirivrc" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Huaye Electric Vehicle Technology Co., Ltd. (Formerly Guangzhou Panyu Huanan Motors Group Co., Ltd.) (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (Truck - Terminal Tractor)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 18X || Western Recreational Vehicles
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-

| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J5 || Big Dog Motorcycles
|-
| 5J5 || Club Car
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Trailers LLC (truck trailer)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51Z || Monaco RV (incomplete vehicle) manufatcured by Navistar RV LLC
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailers (truck trailer)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>dbhyckicxf6ex60n8r6sfreseirivrc</sha1>
    </revision>
    <revision>
      <id>4657080</id>
      <parentid>4657079</parentid>
      <timestamp>2026-08-10T16:50:52Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657080</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="135966" sha1="b5mc0ymq9ls92l8wa0iptuthmbxenpk" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Huaye Electric Vehicle Technology Co., Ltd. (Formerly Guangzhou Panyu Huanan Motors Group Co., Ltd.) (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/484 || Hughes Trailers (Based in Canyon, TX) (trailer)
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (Truck - Terminal Tractor)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 18X || Western Recreational Vehicles
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-
| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J5 || Big Dog Motorcycles
|-
| 5J5 || Club Car
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Trailers LLC (truck trailer)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51Z || Monaco RV (incomplete vehicle) manufatcured by Navistar RV LLC
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailers (truck trailer)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>b5mc0ymq9ls92l8wa0iptuthmbxenpk</sha1>
    </revision>
    <revision>
      <id>4657082</id>
      <parentid>4657080</parentid>
      <timestamp>2026-08-10T16:56:31Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657082</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="136003" sha1="65m2zj39hmtczk25k6tmksdidajem5g" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Huaye Electric Vehicle Technology Co., Ltd. (Formerly Guangzhou Panyu Huanan Motors Group Co., Ltd.) (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/484 || Hughes Trailers (Based in Canyon, TX) (trailer)
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (Truck - Terminal Tractor)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 18X || Western Recreational Vehicles
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-
| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer, Inc. (Formerly Advance Mixer, Inc.) (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J5 || Big Dog Motorcycles
|-
| 5J5 || Club Car
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Trailers LLC (truck trailer)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51Z || Monaco RV (incomplete vehicle) manufatcured by Navistar RV LLC
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailers (truck trailer)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>65m2zj39hmtczk25k6tmksdidajem5g</sha1>
    </revision>
    <revision>
      <id>4657083</id>
      <parentid>4657082</parentid>
      <timestamp>2026-08-10T17:15:26Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657083</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="136072" sha1="55m1zl5utdfjlujwlyomhz95pr9qygl" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Huaye Electric Vehicle Technology Co., Ltd. (Formerly Guangzhou Panyu Huanan Motors Group Co., Ltd.) (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles through mid-2002
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/484 || Hughes Trailers (Based in Canyon, TX) (trailer)
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (Truck - Terminal Tractor)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 18X || Western Recreational Vehicles
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company (Mid-1995 – )
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-
| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer, Inc. (Formerly Advance Mixer, Inc.) (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J1 || Big Dog Motorcycles (Mid-2002 – )
|-
| 5J5 || Club Car (low-speed vehicle)
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Trailers LLC (truck trailer)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51Z || Monaco RV (incomplete vehicle) manufatcured by Navistar RV LLC
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailers (truck trailer)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>55m1zl5utdfjlujwlyomhz95pr9qygl</sha1>
    </revision>
    <revision>
      <id>4657084</id>
      <parentid>4657083</parentid>
      <timestamp>2026-08-10T17:20:24Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657084</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="136080" sha1="7pyf7nm6madd5n2kl4uwu205xwma7fa" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Huaye Electric Vehicle Technology Co., Ltd. (Formerly Guangzhou Panyu Huanan Motors Group Co., Ltd.) (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles through mid-2002
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/484 || Hughes Trailers (Based in Canyon, TX) (trailer)
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (Truck - Terminal Tractor)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 18X || Western Recreational Vehicles
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company (Mid-1995 – )
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-
| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer, Inc. (Formerly Advance Mixer, Inc.) (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J1 || Big Dog Motorcycles (Mid-2002 – )
|-
| 5J5 || Club Car (low-speed vehicle)
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Company (truck trailers, truck beds)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51Z || Monaco RV (incomplete vehicle) manufatcured by Navistar RV LLC
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailers (truck trailer)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>7pyf7nm6madd5n2kl4uwu205xwma7fa</sha1>
    </revision>
    <revision>
      <id>4657085</id>
      <parentid>4657084</parentid>
      <timestamp>2026-08-10T17:23:15Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657085</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="136085" sha1="p8hsnkf4ytonooz5ydzuvjyeno6m7t5" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Huaye Electric Vehicle Technology Co., Ltd. (Formerly Guangzhou Panyu Huanan Motors Group Co., Ltd.) (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles through mid-2002
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/484 || Hughes Trailers (Based in Canyon, TX) (trailer)
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (Truck - Terminal Tractor)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 18X || Western Recreational Vehicles
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company (Mid-1995 – )
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-
| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer, Inc. (Formerly Advance Mixer, Inc.) (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J1 || Big Dog Motorcycles (Mid-2002 – )
|-
| 5J5 || Club Car (low-speed vehicle)
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Company (truck trailers, truck beds)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51Z || Monaco RV (incomplete vehicle) manufatcured by Navistar RV LLC
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailer Mfg. (truck trailers)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>p8hsnkf4ytonooz5ydzuvjyeno6m7t5</sha1>
    </revision>
    <revision>
      <id>4657110</id>
      <parentid>4657085</parentid>
      <timestamp>2026-08-10T22:24:56Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657110</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="136448" sha1="gh7t33v6lznes8ial9nxoenooj2cchw" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Huaye Electric Vehicle Technology Co., Ltd. (Formerly Guangzhou Panyu Huanan Motors Group Co., Ltd.) (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles through mid-2002
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/484 || Hughes Trailers (Based in Canyon, TX) (trailer)
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company (truck)
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1KB || Holiday Rambler Corp. 1981-2010 (trailer)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation (incomplete vehicle)
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (Truck - Terminal Tractor)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 18X || Western Recreational Vehicles
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company (Mid-1995 – )
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-
| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer, Inc. (Formerly Advance Mixer, Inc.) (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J1 || Big Dog Motorcycles (Mid-2002 – )
|-
| 5J5 || Club Car (low-speed vehicle)
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Company (truck trailers, truck beds)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51T || Monaco RV LLC/Navistar RV LLC: Monaco (trailer)
|-
| 51U || Monaco RV LLC/Navistar RV LLC: Holiday Rambler 2010- (trailer)
|-
| 51V || Monaco RV LLC/Navistar RV LLC: R-Vision (trailer)
|-
| 51X || Monaco RV LLC/Navistar RV LLC: McKenzie (trailer)
|-
| 51Z || Monaco RV LLC/Navistar RV LLC: Monaco RV [Roadmaster Chassis] (incomplete vehicle) 
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailer Mfg. (truck trailers)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>gh7t33v6lznes8ial9nxoenooj2cchw</sha1>
    </revision>
    <revision>
      <id>4657117</id>
      <parentid>4657110</parentid>
      <timestamp>2026-08-11T00:02:28Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <comment>/* List of Many WMIs */</comment>
      <origin>4657117</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="136496" sha1="h6hgn57uafzx44kfa5u0u0pa9qlvjc7" xml:space="preserve">==World Manufacturer Identifier==
The first three characters uniquely identify the manufacturer of the vehicle using the '''World Manufacturer Identifier''' or '''WMI''' code. A manufacturer that builds fewer than 1000 vehicles per year uses a 9 as the third digit and the 12th, 13th and 14th position of the VIN for a second part of the identification. Some manufacturers use the third character as a code for a vehicle category (e.g., bus or truck), a division within a manufacturer, or both. For example, within 1G (assigned to General Motors in the United States), 1G1 represents Chevrolet passenger cars; 1G2, Pontiac passenger cars; and 1GC, Chevrolet trucks. 

===WMI Regions===
The first character of the WMI is the region in which the manufacturer is located. In practice, each is assigned to a country of manufacture. Common auto-manufacturing countries are noted. &lt;ref&gt;{{cite web
| url=https://standards.iso.org/iso/3780/
| title=ISO Standards Maintenance Portal: ISO 3780
| publisher=[[wikipedia:International Organization for Standardization]]}}&lt;/ref&gt;

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! WMI
! Region
! Notes
|-
| A-C
| Africa
| AA-AH = South Africa&lt;br /&gt;BF-BG = Kenya&lt;br /&gt;BU = Uganda&lt;br /&gt;CA-CB = Egypt&lt;br /&gt;DF-DK = Morocco
|-
| E, H-R
| Asia
| E=Russia&lt;br /&gt;H = China&lt;br /&gt;J = Japan&lt;br /&gt;KF-KH = Israel&lt;br /&gt;KL-KR = South Korea&lt;br /&gt;L = China&lt;br /&gt;MA-ME = India&lt;br /&gt;MF-MK = Indonesia&lt;br /&gt;ML-MR = Thailand&lt;br /&gt;MS = Myanmar&lt;br /&gt;MX = Kazakhstan&lt;br /&gt;MY-M0 = India&lt;br /&gt;NF-NG = Pakistan&lt;br /&gt;NL-NR = Turkey&lt;br /&gt;NS-NT = Uzbekistan&lt;br /&gt;PA-PC = Philippines&lt;br /&gt;PF-PG = Singapore&lt;br /&gt;PL-PR = Malaysia&lt;br /&gt;PS-PT = Bangladesh&lt;br /&gt;PV=Cambodia&lt;br /&gt;RA-RB = United Arab Emirates&lt;br /&gt;RF-RK = Taiwan&lt;br /&gt;RL-RN = Vietnam&lt;br /&gt;RS-RT = Saudi Arabia&lt;br /&gt;RU-RW = Russia&lt;br /&gt;R1-R7 = Hong Kong

|-
| S-Z
| Europe
| SA-SM = United Kingdom&lt;br /&gt;SN-ST = Germany (formerly East Germany)&lt;br /&gt;SU-SZ = Poland&lt;br /&gt;TA-TH = Switzerland&lt;br /&gt;TJ-TP = Czech Republic&lt;br /&gt;TR-TV = Hungary&lt;br /&gt;TW-T2 = Portugal&lt;br /&gt;UH-UM = Denmark&lt;br /&gt;UN-UR = Ireland&lt;br /&gt;UU-UX = Romania&lt;br /&gt;U1-U2 = North Macedonia&lt;br /&gt;U5-U7 = Slovakia&lt;br /&gt;VA-VE = Austria&lt;br /&gt;VF-VR = France&lt;br /&gt;VS-VW = Spain&lt;br /&gt;VX-V2 = France (formerly Serbia/Yugoslavia)&lt;br /&gt;V3-V5 = Croatia&lt;br /&gt;V6-V8 = Estonia&lt;br /&gt; W = Germany (formerly West Germany)&lt;br /&gt;XA-XC = Bulgaria&lt;br /&gt;XF-XH = Greece&lt;br /&gt;XL-XR = The Netherlands&lt;br /&gt;XS-XW = Russia (formerly USSR)&lt;br /&gt;XX-XY = Luxembourg&lt;br /&gt;XZ-X0 = Russia&lt;br /&gt;YA-YE = Belgium&lt;br /&gt;YF-YK = Finland&lt;br /&gt;YS-YW = Sweden&lt;br /&gt;YX-Y2 = Norway&lt;br /&gt;Y3-Y5 = Belarus&lt;br /&gt;Y6-Y8 = Ukraine&lt;br /&gt;ZA-ZU = Italy&lt;br /&gt;ZX-ZZ = Slovenia&lt;br /&gt;Z3-Z5 = Lithuania&lt;br /&gt;Z6-Z0 = Russia
|-
| 1-5
| North America
| 1, 4, 5 = United States&lt;br /&gt;2 = Canada&lt;br /&gt;3 = Mexico&lt;br /&gt;7F-70 = United States
|-
| 6-7
| Oceania
| 6A-6W = Australia&lt;br /&gt;7A-7E = New Zealand&lt;br /&gt;Revised: 6A-6X = Australia&lt;br /&gt;6Y-61 = New Zealand
|-
| 8-9
| South America
| 8A-8E = Argentina&lt;br /&gt;8F-8G = Chile&lt;br /&gt;8L-8N = Ecuador&lt;br /&gt;8S-8T = Peru&lt;br /&gt;8X-8Z = Venezuela&lt;br /&gt;82 = Bolivia&lt;br /&gt;84 = Costa Rica&lt;br /&gt;9A-9E, 91-90 = Brazil&lt;br /&gt;9F-9G = Colombia&lt;br /&gt;9S-9V = Uruguay
|}

{| class=&quot;wikitable&quot; style=&quot;text-align:center&quot;
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3

! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''A''' || colspan=&quot;8&quot; | South Africa || colspan=&quot;2&quot; | Ivory Coast || colspan=&quot;2&quot; | Lesotho || colspan=&quot;2&quot; | Botswana || colspan=&quot;2&quot; | Namibia || colspan=&quot;2&quot; | Madagascar || colspan=&quot;2&quot; | Mauritius || colspan=&quot;2&quot; | Tunisia || colspan=&quot;2&quot; | Cyprus || colspan=&quot;2&quot; | Zimbabwe || colspan=&quot;2&quot; | Mozambique || colspan=&quot;5&quot; | ''Africa''
|-
| '''B''' || colspan=&quot;2&quot; | Angola || colspan=&quot;1&quot; | Ethiopia || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;2&quot; | Kenya || colspan=&quot;1&quot; | Rwanda || colspan=&quot;2&quot; | ''Africa'' || colspan=&quot;1&quot; | Nigeria || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;1&quot; | Algeria || colspan=&quot;1&quot; | ''Africa'' || colspan=&quot;1&quot; | Swaziland || colspan=&quot;1&quot; | Uganda || colspan=&quot;7&quot; | ''Africa''|| colspan=&quot;2&quot; | Libya || colspan=&quot;6&quot; | ''Africa''
|-
| '''C''' || colspan=&quot;2&quot; | Egypt || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Morocco || colspan=&quot;3&quot; | ''Africa'' || colspan=&quot;2&quot; | Zambia || colspan=&quot;21&quot; | ''Africa''
|-
| '''D''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|-
| '''E''' || colspan=&quot;33&quot; | Russia
|-
| '''F''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | 
|-
| '''G'''
|-
| '''H''' || colspan=&quot;33&quot; | China
|-
| '''J''' || colspan=&quot;33&quot; | Japan
|-
| '''K''' || colspan=&quot;5&quot; | ''Asia'' || colspan=&quot;3&quot; | Israel || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;5&quot; | South Korea || colspan=&quot;2&quot; | Jordan || colspan=&quot;6&quot; | ''Asia'' || colspan=&quot;3&quot; | South Korea || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Kyrgyzstan || colspan=&quot;5&quot; | ''Asia'' 
|-
| '''L''' || colspan=&quot;33&quot; | China
|-
| '''M''' || colspan=&quot;5&quot; | India || colspan=&quot;5&quot; | Indonesia || colspan=&quot;5&quot; | Thailand || colspan=&quot;1&quot; | Myanmar || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Mongolia || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;1&quot; | Kazakhstan || colspan=&quot;12&quot; | India
|-
| '''N''' || colspan=&quot;5&quot; | Iran || colspan=&quot;2&quot; | Pakistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Iraq || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Turkey || colspan=&quot;2&quot; | Uzbekistan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Azerbaijan || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;1&quot; | Tajikistan || colspan=&quot;1&quot; | Armenia || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;5&quot; | Iran || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Turkey || colspan=&quot;2&quot; | ''Asia''
|-
| '''P''' || colspan=&quot;3&quot; | Philippines || colspan=&quot;2&quot; | ''Asia'' || colspan=&quot;2&quot; | Singapore || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Malaysia || colspan=&quot;2&quot; | Bangladesh || colspan=&quot;10&quot; | ''Asia'' || colspan=&quot;6&quot; | India 
|-
| '''R''' || colspan=&quot;2&quot; | UAE || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;5&quot; | Taiwan || colspan=&quot;3&quot; | Vietnam || colspan=&quot;1&quot; | Laos || colspan=&quot;1&quot; | ''Asia'' || colspan=&quot;2&quot; | Saudi Arabia || colspan=&quot;3&quot; | Russia || colspan=&quot;3&quot; | ''Asia'' || colspan=&quot;7&quot; | Hong Kong || colspan=&quot;3&quot; | ''Asia''
|-
! &amp;nbsp;
! A
! B
! C
! D
! E
! F
! G
! H
! J
! K
! L
! M
! N
! P
! R
! S
! T
! U
! V
! W
! X
! Y
! Z
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 0
|-
| '''S''' || colspan=&quot;12&quot; | United Kingdom || colspan=&quot;5&quot; | Germany &lt;small&gt;(formerly East Germany)&lt;/small&gt; || colspan=&quot;6&quot; | Poland || colspan=&quot;2&quot; | Latvia || colspan=&quot;1&quot; | Georgia || colspan=&quot;1&quot; | Iceland || colspan=&quot;6&quot; | ''Europe''
|-
| '''T''' || colspan=&quot;8&quot; | Switzerland || colspan=&quot;6&quot; | Czech Republic || colspan=&quot;5&quot; | Hungary || colspan=&quot;6&quot; | Portugal || colspan=&quot;3&quot; | Serbia || colspan=&quot;1&quot; | Andorra || colspan=&quot;2&quot; | Netherlands || colspan=&quot;2&quot; | ''Europe''
|-
| '''U''' || colspan=&quot;3&quot; | Spain || colspan=&quot;4&quot; | ''Europe'' || colspan=&quot;5&quot; | Denmark || colspan=&quot;3&quot; | Ireland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;4&quot; | Romania || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;2&quot; | North Macedonia || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovakia || colspan=&quot;3&quot; | Bosnia &amp; Herzogovina
|-
| '''V''' || colspan=&quot;5&quot; | Austria || colspan=&quot;10&quot; | France || colspan=&quot;5&quot; | Spain || colspan=&quot;5&quot; | France &lt;small&gt;(formerly Yugoslavia &amp; Serbia)&lt;/small&gt; || colspan=&quot;3&quot; | Croatia || colspan=&quot;3&quot; | Estonia || colspan=&quot;2&quot; | ''Europe''
|-
| '''W''' || colspan=&quot;33&quot; | Germany
|-
| '''X''' || colspan=&quot;3&quot; | Bulgaria || colspan=&quot;2&quot; | Russia || colspan=&quot;3&quot; | Greece || colspan=&quot;2&quot; | Russia || colspan=&quot;5&quot; | Netherlands || colspan=&quot;5&quot; | Russia &lt;small&gt;(formerly USSR)&lt;/small&gt; || colspan=&quot;2&quot; | Luxembourg || colspan=&quot;11&quot; | Russia
|-
| '''Y''' || colspan=&quot;5&quot; | Belgium || colspan=&quot;5&quot; | Finland || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;1&quot; | Malta || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;5&quot; | Sweden || colspan=&quot;5&quot; | Norway || colspan=&quot;3&quot; | Belarus || colspan=&quot;3&quot; | Ukraine || colspan=&quot;2&quot; | ''Europe''
|-
| '''Z''' || colspan=&quot;18&quot; | Italy || colspan=&quot;2&quot; | ''Europe'' || colspan=&quot;3&quot; | Slovenia || colspan=&quot;1&quot; | San Marino|| colspan=&quot;1&quot; | ''Europe''|| colspan=&quot;3&quot; | Lithuania || colspan=&quot;5&quot; | Russia
|-
| '''1''' || colspan=&quot;33&quot; | United States
|-
| '''2''' || colspan=&quot;28&quot; | Canada || colspan=&quot;5&quot; | ''North America'' 
|-
| '''3''' || colspan=&quot;21&quot; | Mexico || colspan=&quot;5&quot; | ''North America'' || colspan=&quot;1&quot; | Nicaragua || colspan=&quot;1&quot; | Dom. Rep. || colspan=&quot;1&quot; | Honduras || colspan=&quot;1&quot; | Panama || colspan=&quot;2&quot; | Puerto Rico || colspan=&quot;1&quot; | ''North America'' 
|-
| '''4''' || colspan=&quot;33&quot; rowspan=&quot;2&quot; | United States
|-
| '''5''' 
|-
| '''6''' || colspan=&quot;21&quot; | Australia || colspan=&quot;3&quot; | New Zealand || colspan=&quot;9&quot; | ''Oceania''
|-
| '''7''' || colspan=&quot;5&quot; | New Zealand || colspan=&quot;28&quot; | United States
|-
| '''8''' || colspan=&quot;5&quot; | Argentina || colspan=2 | Chile || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Ecuador || colspan=&quot;2&quot; | ''South America'' || colspan=&quot;2&quot; | Peru || colspan=&quot;3&quot; | ''South America'' || colspan=&quot;3&quot; | Venezuela || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Bolivia || colspan=&quot;1&quot; | ''SA'' || colspan=&quot;1&quot; | Costa Rica || colspan=&quot;6&quot; | ''South America'' 
|-
| '''9''' || colspan=&quot;5&quot; | Brazil || colspan=&quot;2&quot; | Colombia || colspan=&quot;8&quot; | ''South America''  || colspan=&quot;4&quot; | Uruguay || colspan=&quot;4&quot; | ''South America'' || colspan=&quot;10&quot; | Brazil 
|-
| '''0''' || colspan=&quot;33&quot; rowspan=&quot;1&quot; | 
|}

===List of Many WMIs===
The [[w:Society of Automotive Engineers|Society of Automotive Engineers]] (SAE) in the US assigns WMIs to countries and manufacturers.&lt;ref&gt;{{cite web
| url=https://www.iso.org/standard/45844.html
| title=ISO 3780:2009 - Road vehicles — World manufacturer identifier (WMI) code
| date=October 2009
| publisher=International Organization for Standardization}}&lt;/ref&gt; The following table contains a list of mainly commonly used WMIs, although there are many others assigned.

{| class=&quot;wikitable x&quot; style=&quot;text-align:center&quot;
|-
! WMI !! Manufacturer
|-
| AAA|| Audi South Africa made by Volkswagen of South Africa
|-
| AAK|| FAW Vehicle Manufacturers SA (PTY) Ltd.
|-
| AAM|| MAN Automotive (South Africa) (Pty) Ltd. (includes VW Truck &amp; Bus)
|-
|AAP || VIN restamped by South African Police Service (so-called SAPVIN or AAPV number)
|-
| AAV || Volkswagen South Africa
|-
| AAW || Challenger Trailer Pty Ltd. (South Africa)
|-
| AA9/CN1 || TR-Tec Pty Ltd. (South Africa)
|-
| ABJ || Mitsubishi Colt &amp; Triton pickups made by Mercedes-Benz South Africa 1994–2011
|-
| ABJ || Mitsubishi Fuso made by Daimler Trucks &amp; Buses Southern Africa
|-
| ABM || BMW Southern Africa
|-
| ACV || Isuzu Motors South Africa 2018-
|-
| AC5 || [[../Hyundai/VIN Codes|Hyundai]] Automotive South Africa 
|-
| AC9/BM1 || Beamish Beach Buggies (South Africa)
|-
| ADB || Mercedes-Benz South Africa car
|-
| ADD || UD Trucks Southern Africa (Pty) Ltd.
|-
| ADM || General Motors South Africa (includes Isuzu through 2018)
|-
| ADN || Nissan South Africa (Pty) Ltd.
|-
| ADR || Renault Sandero made by Nissan South Africa (Pty) Ltd.
|-
| ADX || Tata Automobile Corporation (SA) Ltd.
|-
| AE9/MT1 || Backdraft Racing (South Africa)
|-
| AFA || Ford Motor Company of Southern Africa &amp; Samcor
|-
| AFB || Mazda BT-50 made by Ford Motor Company of Southern Africa
|-
| AFD || BAIC Automotive South Africa
|-
| AFZ || Fiat Auto South Africa
|-
| AHH || Hino South Africa
|-
| AHM || Honda Ballade made by Mercedes-Benz South Africa 1982–2000
|-
| AHT || Toyota South Africa Motors (Pty.) Ltd.
|-
| BF9/|| KIBO Motorcycles, Kenya
|-
| BUK || Kiira Motors Corporation, Uganda
|-
| BR1 || Mercedes-Benz Algeria (SAFAV MB)
|-
| BRY || FIAT Algeria
|-
| CA3 || MCV bus (Egypt)
|-
| DDY || Geyushi Motors (bus) (Egypt)
|-
| DF9/|| Laraki (Morocco)
|-
| EAA || Aurus Motors (Russia)
|-
| EAN || Evolute (Russia)
|-
| EAU || Elektromobili Manufacturing Rus - EVM (Russia)
|-
| EBE || Sollers-Auto (Russia)
|-
| EBZ || Nizhekotrans bus (Russia)
|-
| ECE || XCITE (Russia)
|-
| ECW || Trans-Alfa bus (Russia)
|-
| HAC || GAC Motor (Aion)
|-
| HA0 || Wuxi Sundiro Electric Vehicle Co., Ltd. (Palla, Parray)
|-
| HA6 || Jiangsu Niu Electric Technology Co., Ltd. (Niu)
|-
| HA7 || Jinan Qingqi KR Motors Co., Ltd.
|-
| HES || smart Automobile Co., Ltd. (Mercedes-Geely joint venture) 
|-
| HGL ||  Farizon Auto van (Geely)
|-
| HGX ||  Wuling Motors commercial vehicle (Geely)
|-
| HHZ || Huazi Automobile
|-
| HJN || Nio, Firefly 
|-
| HJR || Chery Commercial Vehicle (Anhui) Co., Ltd. Jetour made by Chery Commercial Vehicle
|-
| HJZ || Juzhen Chengshi van
|-
| HJ4 || BAW car
|-
| HLX || Li Auto
|-
| HL4 || Zhejiang Morini Vehicle Co., Ltd. &lt;br /&gt;(Moto Morini subsidiary of Taizhou Zhongneng Motorcycle Co., Ltd.)
|-
| HRV || Beijing Henrey Automobile Technology Co., Ltd.
|-
| HT5 || Zhejiang Jianying Locomotive Co., Ltd. (motorcycle)
|-
| HVW || Volkswagen Anhui
|-
| HWM || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| HXM || Xiaomi
|-
| HZ2 || Taizhou Zhilong Technology Co., Ltd (motorcycle)
|-
| H0D || Taizhou Qianxin Vehicle Co., Ltd. (motorcycle)
|-
| H0G || Wisdom (Fujian) Motor Co., Ltd. (bus)
|-
| JAA || Isuzu truck, Holden Rodeo TF, Opel Campo, Bedford/Vauxhall Brava pickup made by Isuzu in Japan
|-
| JAB || Isuzu car
|-
| JAC || Isuzu SUV, Opel/Vauxhall Monterey &amp; Holden Jackaroo/Monterey made by Isuzu in Japan
|-
| JAE || Acura SLX made by Isuzu
|-
| JAL || Isuzu commercial trucks &amp; &lt;br /&gt; Chevrolet commercial trucks made by Isuzu 2016+ &amp; &lt;br /&gt; Hino S-series truck made by Isuzu (Incomplete Vehicle - medium duty)
|-
| JAM || Isuzu commercial trucks (Incomplete Vehicle - light duty)
|-
| JA3 || Mitsubishi car (for North America)
|-
| JA4 || Mitsubishi MPV/SUV (for North America) &amp; Nissan Rogue PHEV '26
|-
| JA7 || Mitsubishi truck (for North America)
|-
| JB3 || Dodge car made by Mitsubishi Motors
|-
| JB4 || Dodge MPV/SUV made by Mitsubishi Motors
|-
| JB7 || Dodge truck made by Mitsubishi Motors
|-
| JC0 || Ford brand cars made by Mazda
|-
| JC1 || Fiat 124 Spider made by Mazda
|-
| JC2 || Ford Courier made by Mazda
|-
| JDA || Daihatsu, Subaru Justy made by Daihatsu
|-
| JD1 || Daihatsu car
|-
| JD2 || Daihatsu SUV
|-
| JD4 || Daihatsu truck
|-
| JE3 || Eagle car made by Mitsubishi Motors
|-
| JE4 || Mitsubishi Motors
|-
| JF1 || ([[../Subaru/VIN Codes|Subaru]]) car
|-
| JF2 || ([[../Subaru/VIN Codes|Subaru]]) SUV
|-
| JF3 || ([[../Subaru/VIN Codes|Subaru]]) truck
|-
| JF4 || Saab 9-2X made by Subaru
|-
| JG1 || Chevrolet/Geo car made by Suzuki
|-
| JG2 || Pontiac car made by Suzuki
|-
| JG7 || Pontiac/Asuna car made by Suzuki for GM Canada
|-
| JGC || Chevrolet/Geo SUV made by Suzuki (classified as a truck)
|-
| JGT || GMC SUV made by Suzuki for GM Canada (classified as a truck)
|-
| JHA || Hino truck
|-
| JHB || Hino incomplete vehicle
|-
| JHD || Hino
|-
| JHF || Hino
|-
| JHH || Hino incomplete vehicle
|-
| JHF-JHG, JHL-JHN, JHZ,&lt;br/&gt;JH1-JH5 || [[../Honda/VIN Codes|Honda]]
|-
| JHL || [[../Honda/VIN Codes|Honda]] MPV/SUV
|-
| JHM || [[../Honda/VIN Codes|Honda]] car
|-
| JH1 || [[../Honda/VIN Codes|Honda]] truck
|-
| JH2 || [[../Honda/VIN Codes|Honda]] motorcycle/ATV
|-
| JH3 || [[../Honda/VIN Codes|Honda]] ATV
|-
| JH4 || Acura car
|-
| JH6 || Hino incomplete vehicle
|-
| JJ3 || Chrysler brand car made by Mitsubishi Motors
|-
| JKA || Kawasaki (motorcycles)
|-
| JKB || Kawasaki (motorcycles)
|-
| JKM || Mitsuoka
|-
| JKS || Suzuki Marauder 1600/Boulevard M95 motorcycle made by Kawasaki
|-
| JK8 || Suzuki QUV620F UTV made by Kawasaki
|-
| JLB || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLF || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JLS || Sterling Truck 360 made by Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL5 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL6 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JL7 || Mitsubishi Fuso Truck &amp; Bus Corp.
|-
| JMA || Mitsubishi Motors (right-hand drive) for Europe
|-
| JMB || Mitsubishi Motors (left-hand drive) for Europe
|-
| JMF || Mitsubishi Motors for Australia (including Mitsubishi Express made by Renault)
|-
| JMP || Mitsubishi Motors (left-hand drive)
|-
| JMR || Mitsubishi Motors (right-hand drive)
|-
| JMY || Mitsubishi Motors (left-hand drive) for South America &amp; Middle East
|-
| JMZ || Mazda for Europe export &amp; Mazda 2 made by Ford Spain &amp; Mazda 2 Hybrid made by Toyota Motor Manufacturing France
|-
| JM0 || Mazda for Oceania export
|-
| JM1 || Mazda car
|-
| JM2 || Mazda truck
|-
| JM3 || Mazda MPV/SUV
|-
| JM4 || Mazda
|-
| JM6 || Mazda
|-
| JM7 || Mazda
|-
| JNA || Nissan Diesel/UD Trucks (incomplete vehicle)
|-
| JNC || Nissan Diesel/UD Trucks
|-
| JNE || Nissan Diesel/UD Trucks (truck)
|-
| JNK || Infiniti car
|-
| JNR || Infiniti SUV
|-
| JNX || Infiniti incomplete vehicle
|-
| JN1 || Nissan car &amp; Infiniti car
|-
| JN3 || Nissan incomplete vehicle
|-
| JN6 || Nissan truck/van &amp; Mitsubishi Fuso Canter Van
|-
| JN8 || Nissan MPV/SUV &amp; Infiniti SUV
|-
| JPA || International Trucks made by Nissan Diesel (incomplete vehicle)
|-
| JPB || International Trucks made by Nissan Diesel (tractor truck)
|-
| JPC || Nissan Diesel/UD Trucks
|-
| JPE || International Trucks made by Nissan Diesel (truck)
|-
| JP3 || Plymouth car made by Mitsubishi Motors
|-
| JP4 || Plymouth MPV/SUV made by Mitsubishi Motors
|-
| JP7 || Plymouth truck made by Mitsubishi Motors
|-
| JR2 || Isuzu Oasis made by Honda
|-
| JSA || Suzuki ATV &amp; '03 Kawasaki KFX400 ATV made by Suzuki, Suzuki car/SUV (outside N. America), Holden Cruze YG made by Suzuki
|-
| JSK || Kawasaki KLX125/KLX125L motorcycle made by Suzuki
|-
| JSL || '04-'06 Kawasaki KFX400 ATV made by Suzuki
|-
| JST || Suzuki Across SUV made by Toyota
|-
| JS1 || Suzuki motorcycle &amp; Kawasaki KLX400S/KLX400SR motorcycle made by Suzuki
|-
| JS2 || Suzuki car
|-
| JS3 || Suzuki SUV
|-
| JS4 || Suzuki truck
|-
| JTB || Toyota bus
|-
| JTD || Toyota car
|-
| JTE || Toyota MPV/SUV
|-
| JTF || Toyota van/truck
|-
| JTG || Toyota MPV/bus
|-
| JTH || Lexus car
|-
| JTJ || Lexus SUV
|-
| JTK || Toyota car
|-
| JTL || Toyota SUV
|-
| JTM || Toyota SUV, Subaru Solterra made by Toyota
|-
| JTN || Toyota car
|-
| JTP || Toyota SUV
|-
| JT1 || [[../Toyota/VIN Codes|Toyota]] van
|-
| JT2 || Toyota car
|-
| JT3 || Toyota MPV/SUV
|-
| JT4 || Toyota truck/van
|-
| JT5 || Toyota incomplete vehicle
|-
| JT6 || Lexus SUV
|-
| JT7 || Toyota bus/van
|-
| JT8 || Lexus car
|-
| JW6 || Mitsubishi Fuso division of Mitsubishi Motors (through mid-2003)
|-
| JYA || Yamaha motorcycles
|-
| JYE || Yamaha snowmobile
|-
| JY3 || Yamaha 3-wheel ATV
|-
| JY4 || Yamaha 4-wheel ATV
|-
| J81 || Chevrolet/Geo car made by Isuzu
|-
| J87 || Pontiac/Asüna car made by Isuzu for GM Canada
|-
| J8B || Chevrolet commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8C || Chevrolet commercial trucks made by Isuzu (truck)
|-
| J8D || GMC commercial trucks made by Isuzu (incomplete vehicle - medium duty)
|-
| J8T || GMC commercial trucks made by Isuzu (truck)
|-
| J8Z || Chevrolet LUV pickup truck made by Isuzu (truck)
|-
| KF3 || Merkavim (Israel)
|-
| KF6 || Automotive Industries, Ltd. (Israel)
|-
| KF9/004 || Tomcar (Israel)
|-
| KG9/002 || Charash Ashdod (truck trailer) (Israel)
|-
| KG9/004 || H. Klein (truck trailer) (Israel)
|-
| KG9/007 || Agam Trailers (truck trailer) (Israel)
|-
| KG9/009 || Merkavey Noa (trailer) (Israel)
|-
| KG9/010 || Weingold Trailers (trailer) (Israel)
|-
| KG9/011 || Netzer Sereni (truck trailer) (Israel)
|-
| KG9/015 || Merkaz Hagrorim (trailer) (Israel)
|-
| KG9/035 || BEL Technologies (truck trailer) (Israel)
|-
| KG9/091 || Jansteel (truck trailer) (Israel)
|-
| KG9/101 || Bassamco (truck trailer) (Israel)
|-
| KG9/104 || Global Handasa (truck trailer) (Israel)
|-
| KL || Daewoo [[../GM/VIN Codes|General Motors]] South Korea
|-
| KLA || Daewoo/GM Daewoo/GM Korea (Chevrolet/Alpheon)&lt;br /&gt; from Bupyeong &amp; Kunsan plants
|-
| KLP || CT&amp;T United (battery electric low-speed vehicles)
|-
| KLT || Tata Daewoo
|-
| KLU || Tata Daewoo
|-
| KLY || Daewoo/GM Daewoo/GM Korea (Chevrolet) from Changwon plant (Tico/Matiz/Matiz Creative/Spark/Damas/Labo)
|-
| KL1 || GM Daewoo/GM Korea (Chevrolet car)
|-
| KL2 || Daewoo/GM Daewoo (Pontiac)
|-
| KL3 || GM Daewoo/GM Korea (Holden)
|-
| KL4 || GM Korea (Buick)
|-
| KL5 || GM Daewoo (Suzuki)
|-
| KL6 || GM Daewoo (GMC)
|-
| KL7 || Daewoo (GM Canada brands: Passport, Asuna (Pre-2000))
|-
| KL7 || GM Daewoo/GM Korea (Chevrolet MPV/SUV (Post-2000))
|-
| KL8 || GM Daewoo/GM Korea (Chevrolet car from Changwon plant (Spark))
|-
| KM || [[../Hyundai/VIN Codes|Hyundai]]
|-
| KMC || Hyundai commercial truck
|-
| KME || Hyundai commercial truck (semi-tractor)
|-
| KMF || Hyundai van &amp; commercial truck &amp; Bering Truck
|-
| KMH || Hyundai car &amp; Mexican market Dodges made by Hyundai
|-
| KMJ || Hyundai minibus/bus
|-
| KMT || Genesis Motor car
|-
| KMU || Genesis Motor SUV
|-
| KMX || Hyundai Galloper SUV
|-
| KMY || Daelim Motor Company, Ltd/DNA Motors Co., Ltd. (motorcycles)
|-
| KM1 || Hyosung Motors (motorcycles)
|-
| KM4 || Hyosung Motors/S&amp;T Motors/KR Motors (motorcycles)
|-
| KM8 || Hyundai SUV
|-
| KNA || Kia car
|-
| KNC || Kia truck
|-
| KND || Kia MPV/SUV &amp; Hyundai Entourage
|-
| KNE || Kia for Europe export
|-
| KNF || Kia, special vehicles
|-
| KNG || Kia minibus/bus
|-
| KNJ || Ford Festiva &amp; Aspire made by Kia
|-
| KNL || Kia Elan/Vigato made by Kia Motech
|-
| KNM || Renault Samsung Motors, Nissan Rogue made by Renault Samsung, Nissan Sunny made by Renault Samsung
|-
| KNM || Renault Korea Co., Ltd.
|-
| KN1 || Asia Motors
|-
| KN2 || Asia Motors
|-
| KPA || SsangYong/KG Mobility (KGM) pickup
|-
| KPB || SsangYong car
|-
| KPD || SsangYong TransStar (bus)
|-
| KPH || Mitsubishi Precis
|-
| KPT || SsangYong/KG Mobility (KGM) SUV/MPV
|-
| LAA || Shanghai Jialing Vehicle Co., Ltd. (motorcycle)
|-
| LAE || Jinan Qingqi Motorcycle
|-
| LAL || Sundiro [[../Honda/VIN Codes|Honda]] Motorcycle
|-
| LAN || Changzhou Yamasaki Motorcycle
|-
| LAP || Chongqing Jianshe Motorcycle Co., Ltd.
|-
| LAP || Zhuzhou Nanfang Motorcycle Co., Ltd.
|-
| LAT || Luoyang Northern Ek Chor Motorcycle Co., Ltd. (Dayang)
|-
| LA6 || Xiamen King Long United Automotive Industry Co., Ltd. (bus)
|-
| LA7 || Radar Auto (Geely)
|-
| LA8 || Anhui Ankai
|-
| LA9/AYS || Jiangsu Alfa Bus Co., Ltd. (bus)
|-
| LA9/BFC || Beijing North Huade Neoplan Bus Co., Ltd.
|-
| LA9/FBC || Xiamen Fengtai Bus &amp; Coach International Co., Ltd. (FTBCI) (bus)
|-
| LA9/HFF || Anhui Huaxia Vehicle Manufacturing Co., Ltd. (bus)
|-
| LA9/JXK || CHTC Bonluck Bus Co., Ltd.
|-
| LA9/LC0 || BYD
|-
| LA9/LFJ || Xinlongma Automobile
|-
| LA9/LM6 || SRM Shineray
|-
| LBB || Zhejiang Qianjiang Motorcycle (QJ Motor/Keeway/Benelli)
|-
| LBE || Beijing [[../Hyundai/VIN Codes|Hyundai]] (Hyundai, Shouwang)
|-
| LBM || Zongshen Piaggio
|-
| LBP || Chongqing Jianshe Yamaha Motor Co. Ltd. (motorcycles)
|-
| LBV || BMW Brilliance (BMW, Zinoro)
|-
| LBX || Jiangsu Kinroad Xintian Motorcycle Manufacture Co. Ltd. (motorcycles)
|-
| LBZ || Yantai Shuchi Vehicle Co., Ltd. (bus)
|-
| LB1 || Fujian Benz
|-
| LB2 || Geely Motorcycles
|-
| LB3 || Zhejiang Geely Holding Group (Geely, Galaxy, Geometry, Kandi)
|-
| LB4 || Chongqing Yinxiang Motorcycle Group Co., Ltd.
|-
| LB5 || Foshan City Fosti Motorcycle Co., Ltd.
|-
| LB7 || Tibet New Summit Motorcycle Co., Ltd.
|-
| LCE || Hangzhou Chunfeng Motorcycles (CFMOTO)
|-
| LCR || Gonow
|-
| LC0 || BYD Auto (BYD, Denza)
|-
| LC2 || Changzhou Kwang Yang Motor Co., Ltd. (Kymco)
|-
| LC6 || Changzhou Haojue Suzuki Motorcycle Co. Ltd.
|-
| LDB || Dadi Auto
|-
| LDC || Dongfeng Peugeot Citroen Automobile Co., Ltd. (DPCA), Dongfeng Fengshen (Aeolus) L60
|-
| LDD || Dandong Huanghai Automobile
|-
| LDF || Dezhou Fulu Vehicle Co., Ltd. (motorcycles), BAW Yuanbao electric car (Ace P1 in Norway)
|-
| LDK || FAW Bus (Dalian) Co., Ltd.
|-
| LDN || Soueast (South East (Fujian) Motor Co., Ltd.) including Mitsubishi made by Soueast
|-
| LDP || Dongfeng, Dongfeng Fengshen (Aeolus), Voyah, Renault City K-ZE/Venucia e30 made by eGT New Energy Automotive
|-
| LDY || Zhongtong Bus Holding Co. Ltd.
|-
| LD3 || Guangdong Tayo Motorcycle Technology Co. (Zontes) (motorcycle)
|-
| LD5 || Benzhou Vehicle Industry Group Ltd. (motorcycle)
|-
| LD9/L3A || SiTech (FAW)
|-
| LEC || Tianjin Qingyuan Electric Vehicle Co., Ltd.
|-
| LEF || Jiangling Motors Corporation Ltd. (JMC)
|-
| LEH || Zhejiang Riya Motorcycle Co. Ltd.
|-
| LET || Jiangling-Isuzu Motors, China
|- 
| LEW || Dongfeng commercial vehicle
|- 
| LE4 || Beijing Benz &amp; Beijing Benz-Daimler Chrysler Automotive Co. (Chrysler, Jeep, Mitsubishi, Mercedes-Benz) &amp; Beijing Jeep Corp.
|-
| LE8 || Guangzhou Huaye Electric Vehicle Technology Co., Ltd. (Formerly Guangzhou Panyu Huanan Motors Group Co., Ltd.) (motorcycles)
|-
| LFB || FAW Group (Bestune, Hongqi) &amp; Mazda made under license by FAW (Mazda 8, CX-7)
|-
| LFF || Zhejiang Taizhou Wangye Power Co., Ltd.
|-
| LFG || Taizhou Chuanl Motorcycle Manufacturing
|-
| LFJ || Fujian Motors Group (Keyton)
|-
| LFM || FAW Toyota Motor (Toyota, Ranz)
|-
| LFN || FAW Bus (Wuxi) Co., Ltd. (truck, bus)
|-
| LFP || FAW Car, Bestune, Hongqi (passenger vehicles) &amp; Mazda made under license by FAW (Mazda 6, CX-4)
|-
| LFT || FAW (trailers)
|-
| LFU || Lifeng Group Co., Ltd. (motorcycles)
|-
| LFV || FAW-Volkswagen (VW, Audi, Jetta, Kaili)
|-
| LFW || FAW JieFang (truck)
|-
| LFX || Sany Heavy Industry (truck)
|-
| LFY || Changshu Light Motorcycle Factory
|-
| LFZ || Leapmotor
|-
| LF3 || Lifan Motorcycle 
|-
| LGA || Dongfeng Commercial Vehicle Co., Ltd. trucks
|-
| LGB || Dongfeng Nissan (Nissan, Infiniti, Venucia)
|-
| LGB || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGC || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGD || Dongfeng Commercial Vehicle Co., Ltd. 
|-
| LGF || Dongfeng Commercial Vehicle Co., Ltd. bus chassis
|-
| LGG || Dongfeng Liuzhou Motor (Forthing/Fengxing)
|-
| LGJ || Dongfeng Fengshen (Aeolus)
|-
| LGL || Guilin Daewoo
|-
| LGV || Heshan Guoji Nanlian Motorcycle Industry Co., Ltd.
|-
| LGW || Great Wall Motor (GWM, Haval, Ora, Tank, Wey)
|-
| LGX || BYD Auto (BYD, Fangchengbao)
|-
| LGZ || Guangzhou Denway Bus
|-
| LG6 || Dayun Group
|-
| LHA || Shuanghuan Auto
|-
| LHB || Beijing Automotive Industry Holding
|-
| LHG || GAC Honda (Honda, Everus, Acura)
|-
| LHJ || Chongqing Astronautic Bashan Motorcycle Manufacturing Co., Ltd.
|-
| LHM || Dongfeng Renault Automobile Co.
|-
| LHW || CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LH0 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LH1 || FAW-Haima, China
|-
| LJC || Jincheng Corporation
|-
| LJD || Yueda Kia (previously Dongfeng Yueda Kia) (Kia, Horki) &amp; Human Horizons - HiPhi (made under contract by Yueda Kia)
|-
| LJM || Sunlong (bus)
|-
| LJN || Zhengzhou Nissan
|-
| LJR || CIMC Vehicles Group (truck trailer)
|-
| LJS || Yaxing Coach, Asiastar Bus
|-
| LJU || Shanghai Maple Automobile &amp; Kandi &amp; Zhidou
|-
| LJU || Lotus Technology (Wuhan Lotus Cars Co., Ltd.)
|-
| LJV || Sinotruk Chengdu Wangpai Commercial Vehicle Co., Ltd.
|-
| LJW || JMC Landwind
|-
| LJX || JMC Ford
|-
| LJ1 || JAC (JAC, Sehol)
|-
| LJ1 || Nio, Inc.
|-
| LJ4 || Shanghai Jmstar Motorcycle Co., Ltd.
|-
| LJ5 || Cixi Kingring Motorcycle Co., Ltd. (Jinlun)
|-
| LJ8 || Zotye Auto made by Jiangnan Automobile
|-
| LKC || BAIC commercial vehicles, previously Changhe
|-
| LKG || Youngman Lotus Automobile Co., Ltd.
|-
| LKH || Hafei Motor
|-
| LKL || Higer Bus
|-
| LKT || Yunnan Lifan Junma Vehicle Co., Ltd. commercial vehicles
|-
| LK2 || Anhui JAC Bus
|-
| LK6 || SAIC-GM-Wuling (Wuling, Baojun) microcars and other vehicles
|-
| LK8 || Zhejiang Yule New Energy Automobile Technology Co., Ltd. (ATV)
|-
| LLC || Loncin Motor Co., Ltd. (motorcycle)
|-
| LLJ || Jiangsu Xinling Motorcycle Fabricate Co., Ltd.
|-
| LLN || Qoros 
|-
| LLP || Zhejiang Jiajue Motorcycle Manufacturing Co., Ltd.
|-
| LLU || Dongfeng Fengxing Jingyi
|-
| LLV || Lifan, Maple (owned by Geely), Livan Automotive
|-
| LLX || Yudo Auto
|-
| LL0 || Sanmen County Yongfu Machine Co., Ltd. (motorcycles)
|-
| LL2 || WM Motor Technology Co., Ltd. (Weltmeister)
|-
| LL3 || Xiamen Golden Dragon Bus Co. Ltd.
|-
| LL6 || GAC Mitsubishi Motors Co., Ltd. (formerly Hunan Changfeng)
|-
| LL8 || Jiangsu Linhai Yamaha Motor Co., Ltd.
|-
| LMC || Suzuki Hong Kong (motorcycles)
|-
| LME || Skyworth (formerly Skywell), Elaris Beo
|-
| LMF || Jiangmen Zhongyu Motor Co., Ltd.
|-
| LMG || GAC Motor, Trumpchi, [[w:Dodge Attitude#Fourth generation (2025)|Dodge Attitude made by GAC]]
|-
| LMH || Jiangsu Guowei Motor Co., Ltd. (Motoleader)
|-
| LMP || Geely Sichuan Commercial Vehicle Co., Ltd.
|-
| LMV || Haima Car Co., Ltd.
|-
| LMV || XPeng Motors G3 (not G3i) made by Haima
|-
| LMW || GAC Group, [[w:Trumpchi GS5#Dodge Journey|Dodge Journey made by GAC]]
|-
| LMX || Forthing (Dongfeng Fengxing)
|-
| LM0 || Wangye Holdings Co., Ltd. (motorcycles)
|-
| LM6 || SWM (automobiles)
|-
| LM8 || Seres (formerly SF Motors), AITO
|-
| LNA || GAC Aion New Energy Automobile Co., Ltd., Hycan
|-
| LNB || BAIC Motor (Senova, Weiwang, Huansu) &amp; Arcfox &amp; Xiaomi SU7 built by BAIC
|-
| LND || JMEV (Jiangxi Jiangling Group New Energy Vehicle Co., Ltd.), Eveasy/Mobilize Limo
|-
| LNE || Zhejiang CRRC Electric Vehicle Co., Ltd. (bus)
|-
| LNP || NAC MG UK Limited &amp; Nanjing Fiat Automobile
|-
| LNN || Chery Automobile, Omoda, Jaecoo
|-
| LNV || Naveco (Nanjing Iveco Automobile Co. Ltd.)
|-
| LNX || Dongfeng Liuzhou Motor (Chenglong trucks)
|-
| LNY || Yuejin
|-
| LPA || Changan PSA (DS Automobiles)
|-
| LPE || BYD Auto
|-
| LPS || Polestar
|-
| LP6 || Guangzhou Panyu Haojian Motorcycle Industry Co., Ltd.
|-
| LRB || SAIC-General Motors (Buick for export)
|-
| LRD || Beijing Foton Daimler Automotive Co., Ltd. Auman trucks
|-
| LRE || SAIC-General Motors (Cadillac for export)
|-
| LRP || Chongqing Rato Power Co. Ltd. (Asus)
|-
| LRR || Ningbo Longjia Power Technology Co., Ltd. (motorcycles)
|-
| LRW || Tesla, Inc. (Gigafactory Shanghai)
|-
| LR4 || Yadi Technology Group
|-
| LR6 || Guangzhou Dayun Vehicle Co., Ltd.
|-
| LSC || Changan Automobile (light truck)
|-
| LSF || SAIC Maxus or LDV pickup/SUV &amp; Chevrolet S10 Max &amp; Shanghai Sunwin Bus Corporation
|-
| LSG || SAIC-General Motors (For China: Chevrolet, Buick, Cadillac, Sail Springo, For export: Chevrolet)
|-
| LSH || SAIC Maxus van or LDV van &amp; Chevrolet Express Max
|-
| LSJ || SAIC MG &amp; SAIC Roewe &amp; IM Motors &amp; Rising Auto
|-
| LSK || SAIC Maxus or LDV van
|-
| LSV || SAIC-Volkswagen (VW, Skoda, Audi, Tantus)
|-
| LSY || Brilliance (Jinbei, Zhonghua) &amp; Jinbei GM
|-
| LS3 || Hejia New Energy Vehicle Co., Ltd
|-
| LS4 || Changan Automobile (MPV/SUV)
|-
| LS5 || Changan Automobile (car) &amp; Changan Suzuki
|-
| LS6 || Changan Automobile &amp; Deepal Automobile &amp; Avatr
|-
| LS7 || JMC Heavy Duty Truck Co., Ltd.
|-
| LS8 ||Henan Shaolin Auto Co., Ltd. (bus)
|-
| LTA || ZX Auto
|-
| LTN || Soueast-built Chrysler &amp; Dodge vehicles
|-
| LTP || National Electric Vehicle Sweden AB (NEVS)
|-
| LTV || FAW [[../Toyota/VIN Codes|Toyota]] (Tianjin)
|-
| LTW || Zhejiang Dianka Automobile Technology Co. Ltd. (Enovate) 
|-
| LT1 || Yangzhou Tonghua Semi-Trailer Co., Ltd. (truck trailer)
|-
| LUC || [[../Honda/VIN Codes|Honda]] Automobile (China)
|-
| LUD || Dongfeng Nissan Diesel Motor Co Ltd.
|-
| LUG || Qiantu Motor
|-
| LUJ || Zhejiang Shanqi Tianying Vehicle Industry Co., Ltd. (motorcycles)
|-
| LUR || Chery Automobile, iCar
|-
| LUX || Dongfeng Yulon Motor Co. Ltd.
|-
| LUZ || Hozon Auto New Energy Automobile Co., Ltd. (Neta)
|-
| LVA || Foton Motor
|-
| LVB || Foton Motor truck
|-
| LVC || Foton Motor bus
|-
| LVF || Changhe Suzuki
|-
| LVG || GAC Toyota (Toyota, Leahead)
|-
| LVH || Dongfeng Honda (Honda, Ciimo)
|-
| LVM || Chery Commercial Vehicle
|-
| LVP || Dongfeng Sokon Motor Company (DFSK)
|-
| LVR || Changan Mazda
|-
| LVS || Changan [[../Ford/VIN Codes|Ford]] (Ford, Lincoln) &amp; Changan Ford Mazda &amp; Volvo S40 and S80L made by Changan Ford Mazda
|-
| LVT || Chery Automobile, Exeed, Jetour, Soueast
|-
| LVU || Chery Automobile, Jetour
|-
| LVV || Chery Automobile, Omoda, Jaecoo
|-
| LVX || Landwind, JMC (discontinued in 2021)
|-
| LVX || Aiways Automobiles Company Ltd
|-
| LVY || Volvo Cars Daqing factory
|-
| LVZ || Dongfeng Sokon Motor Company (DFSK)
|-
| LV3 || Hengchi Automobile (Evergrande Group)
|-
| LV7 || Jinan Qingqi Motorcycle
|-
| LWB || Wuyang Honda Motorcycle (Guangzhou) Co., Ltd.
|-
| LWE || Yangtse Motor Group (bus)
|-
| LWG || Chongqing Huansong Industries (Group) Co., Ltd.
|-
| LWL || Qingling Isuzu
|-
| LWM || Chongqing Wonjan Motorcycle Co., Ltd.
|-
| LWV || GAC Fiat Chrysler Automobiles (Fiat, Jeep)
|-
| LWX || Shanghai Wanxiang Automobile Manufacturing Co., Ltd. (bus)
|-
| LW4 || Li Auto
|-
| LXA || Jiangmen Qipai Motorcycle Co., Ltd.
|-
| LXD || Ningbo Dongfang Lingyun Vehicle Made Co., Ltd. (motorcycle)
|-
| LXG || Xuzhou Construction Machinery Group Co., Ltd. (XCMG)
|-
| LXK || Shanghai Meitian Motorcycle Co., Ltd.
|-
| LXM || Xiamen Xiashing Motorcycle Co., Ltd. (SYM)
|-
| LXN || Link Tour
|-
| LXV || Beijing Borgward Automotive Co., Ltd.
|-
| LXW || JMC - Ford
|-
| LXY || Chongqing Shineray Motorcycle Co., Ltd.
|-
| LX6 || Jiangmen City Huari Group Co. Ltd. (motorcycle)
|-
| LX8 || Chongqing Xgjao (Xinganjue) Motorcycle Co Ltd.
|-
| LYB || Weichai (Yangzhou) Yaxing Automobile Co., Ltd.
|-
| LYD || Taizhou City Kaitong Motorcycle Co., Ltd. (motorcycle)
|-
| LYJ || Beijing ZhongdaYanjing Auto Co., Ltd. (bus)
|-
| LYM || Zhuzhou Jianshe Yamaha Motorcycle Co., Ltd.
|-
| LYS || Nanjing Vmoto Manufacturing Co. Ltd. (motorcycle)
|-
| LYU || Huansu (BAIC Motor &amp; Yinxiang Group)
|-
| LYV || Volvo Cars Chengdu factory &amp; Taizhou, Luqiao District factory
|-
| LY4 || Chongqing Yingang Science &amp; Technology Group Co., Ltd. (motorcycle)
|-
| LZE || Isuzu Guangzhou, China
|-
| LZF || SAIC Iveco Hongyan (-2021), SAIC Hongyan (2021-)
|-
| LZG || Shaanxi Automobile Group (Shacman)
|-
| LZK || Sinotruk (CNHTC) Huanghe bus
|-
| LZL || Zengcheng Haili Motorcycle Ltd.
|-
| LZM || MAN China
|-
| LZP || Zhongshan Guochi Motorcycle (Baotian)
|-
| LZS || Zongshen, Electra Meccanica Vehicles Corp. (Solo) made by Zongshen
|-
| LZU || Guangzhou Isuzu Bus
|-
| LZW || SAIC-GM-Wuling (Wuling, Baojun, Chevrolet [for export])
|-
| LZY || Yutong Bus Co., Ltd.
|-
| LZZ || Sinotruk (CNHTC) (Howo, Sitrak)
|-
| LZ0 || Shandong Wuzheng Group Co., Ltd.
|-
| LZ4 || Jiangsu Linzhi Shangyang Group Co Ltd.
|-
| LZ9/LZX || Raysince
|-
| L0N || Ezytrail (camper trailers)
|-
| L08 || Zhejiang Apollo Sports Technology Co., Ltd. (motorcycles)
|-
| L1K || Chongqing Hengtong Bus Co., Ltd.
|-
| L1N || XPeng Motors
|-
| L10 || Geely Emgrand
|-
| L2B || Jiangsu Baodiao Locomotive Co., Ltd. (motorcycles)
|-
| L2C || Chery Jaguar Land Rover
|-
| L3H || Shanxi Victory Automobile Manufacturing Co., Ltd.
|-
| L37 || Huzhou Daixi Zhenhua Technology Trade Co., Ltd. (motorcycles)
|-
| L4B || Xingyue Group (motorcycles)
|-
| L4F || Suzhou Eagle Electric Vehicle Manufacturing Co., Ltd.
|-
| L4H || Ningbo Longjia Motorcycle Co., Ltd.
|-
| L4S || Zhejiang Xingyue Vehicle Co Ltd. (motorcycles)
|-
| L4Y || Qingqi Group Ningbo Rhon Motorcycle / Ningbo Dalong Smooth Locomotive Industry Co., Ltd.
|-
| L5C || Zhejiang Kangdi Vehicles Co., Ltd. (motorcycles, ATVs)
|-
| L5E || Zoomlion Heavy Industry Science &amp; Technology Co., Ltd.
|-
| L5K || Zhejiang Yongkang Easy Vehicle
|-
| L5N || Zhejiang Taotao (ATV &amp; motorcycles)
|-
| L5R || Jiangsu Dafier Motorcycle Co., Ltd. (motorcycles)
|-
| L5Y || Taizhou Zhongneng Motorcycle Co. Ltd. (Znen)
|-
| L6F || Shandong Liangzi Power Co. Ltd.
|-
| L6J || Zhejiang Kayo Motor Co. Ltd. (ATV)
|-
| L6K || Shanghai Howhit Machinery Manufacture Co. Ltd.
|-
| L6T || Geely, Lynk &amp; Co, Zeekr
|-
| L66 || Zhuhai Granton Bus and Coach Co. Ltd. 
|-
| L82 || Baotian
|-
| L85 || Zhejiang Yongkang Huabao Electric Appliance
|-
| L8A || Jinhua Youngman Automobile Manufacturing Co., Ltd.
|-
| L8X || Zhejiang Summit Huawin Motorcycle
|-
| L8Y || Zhejiang Jonway Motorcycle Manufacturing Co., Ltd.
|-
| L9G || Zhuhai Guangtong Automobile Co., Ltd. (bus)
|-
| L9N || Zhejiang Taotao Vehicles Co., Ltd.
|-
| MAA || India Kawasaki Motors Pvt. Ltd.
|-
| MAB || Mahindra &amp; Mahindra
|-
| MAC || Mahindra &amp; Mahindra
|-
| MAH || Fiat India Automobiles Pvt. Ltd
|-
| MAJ || [[../Ford/VIN Codes|Ford]] India
|-
| MAK || [[../Honda/VIN Codes|Honda]] Cars India
|-
| MAL || Hyundai Motor India
|- 
| MAN || Eicher Polaris Multix
|- 
| MAT || Tata Motors, Rover CityRover
|-
| MA1 || Mahindra &amp; Mahindra
|-
| MA3 || Maruti Suzuki India (domestic &amp; export)
|-
| MA6 || GM India
|-
| MA7 || Hindustan Motors Ltd. &amp; Mitsubishi Motors &amp; Isuzu models made by Hindustan Motors
|-
| MA8 || Daewoo Motor India
|-
| MBF || Royal Enfield
|- 
| MBH || Suzuki (for export) &amp; Nissan Pixo made by Maruti Suzuki India Limited
|-
| MBJ || [[../Toyota/VIN Codes|Toyota]] Kirloskar Motor Pvt. Ltd.
|-
| MBK || MAN Trucks India Pvt. Ltd.
|-
| MBL || Hero MotoCorp
|-
| MBR || Mercedes-Benz India
|-
| MBU || Swaraj Vehicles Limited
|-
| MBV || Premier Automobiles Ltd.
|-
| MBX || Piaggio India (Piaggio Ape)
|-
| MBY || Asia Motor Works Ltd.
|-
| MB1 || Ashok Leyland
|-
| MB2 || Hyundai Motor India (SUV)
|-
| MB7 || Reva Electric Car Company/Mahindra Reva Electric Vehicles Pvt. Ltd.
|-
| MB8 || Suzuki Motorcycle India Limited
|-
| MCA || FCA India Automobiles Pvt. Ltd. (Fiat, Jeep)
|-
| MCB || GM India
|-
| MCD || Mahindra Two Wheelers
|-
| MCG || Atul Auto Ltd.
|-
| MCL || International Cars And Motors Ltd.
|-
| MC1 || Force Motors Ltd.
|-
| MC2 || Eicher Motors Ltd./Volvo Eicher Commercial Vehicles Ltd.
|-
| MC4 || Dilip Chhabria Design Pvt Ltd.
|-
| MC9/RE1 || Reva Electric Car Company (Reva G-Wiz)
|-
| MDE || Kinetic Engineering Limited
|-
| MDH || Nissan Motor India Pvt Ltd. (including Datsun)
|-
| MDT || Kerala Automobiles Limited
|-
| MD2 || Bajaj Auto Ltd. &amp; KTM and Husqvarna motorcycles built by Bajaj &amp; Indian-market Triumph motorcycles built by Bajaj
|-
| MD6 || TVS Motor Company
|-
| MD7 || LML Ltd including Genuine Scooter Company Stella
|-
| MD9 || Shuttle Cars India
|-
| MEC || Daimler India Commercial Vehicles (BharatBenz)
|-
| MEE || Renault India Private Limited
|-
| MEG || Harley-Davidson India
|-
| MER || Benelli India
|-
| MES || Mahindra Navistar
|-
| MET || Piaggio India (Vespa, Indian-market Aprilia)
|-
| MEX || Škoda Auto Volkswagen India Pvt. Ltd. 2015 on
|-
| ME1 || India Yamaha Motor Pvt. Ltd.
|-
| ME3 || Royal Enfield
|-
| ME4 || Honda Motorcycle and Scooter India
|-
| MYH || Ather Energy
|-
| MZB || Kia India Pvt. Ltd.
|-
| MZD || Classic Legends Private Limited – Jawa
|-
| MZZ || Citroen India (PCA Automobiles India Private Limited)
|-
| MZ7 || MG Motor India Pvt. Ltd.
|-
| M3G || Isuzu Motors India
|-
| M6F || UM Lohia Two Wheelers Private Limited
|-
| ME9/ || BUYMYEV TECHNOLOGY PVT. LTD. (Indibike)
|-
| MF3 || PT Hyundai Motor Manufacturing Indonesia
|-
| MHB || PT Nissan Motor Indonesia
|-
| MHD || PT Indomobil Suzuki International
|-
| MHF || PT [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Indonesia
|-
| MHK || PT Astra Daihatsu Motor (includes Toyotas made by Astra Daihatsu)
|-
| MHL || PT Mercedes-Benz Indonesia
|-
| MHR || [[../Honda/VIN Codes|Honda]] Indonesia (PT Honda Prospect Motor) (car)
|-
| MHY || PT Suzuki Indomobil Motor (car, MPV, van)
|-
| MH1 || PT Astra Honda Motor (motorcycle)
|-
| MH3 || PT Yamaha Indonesia Motor Mfg.
|-
| MH4 || PT Kawasaki Motor Indonesia
|-
| MH8 || PT Suzuki Indomobil Motor (motorcycle)
|-
| MJB || GM Indonesia
|-
| MKF || PT Sokonindo Automobile (DFSK)
|-
| MK2 || PT Mitsubishi Motors Krama Yudha Indonesia
|-
| MK3 || PT SGMW Motor Indonesia (Wuling)
|-
| MLB || Siam Yamaha Co Ltd.
|-
| MLC || Thai Suzuki Motor Co., Ltd. (motorcycle)
|-
| MLE || Thai Yamaha Motor Co., Ltd.
|-
| MLH || Thai [[../Honda/VIN Codes|Honda]] Manufacturing Co., Ltd. (motorcycle)
|-
| MLW || Sco Motor Co., Ltd. (motorcycle)
|-
| MLY || Harley-Davidson Thailand
|-
| ML0 || Ducati Motor (Thailand) Co., Ltd.
|-
| ML3 || Mitsubishi Motors, Dodge Colt 100 [Canada], [[w:Dodge Attitude#Third generation (A10; 2015)|Dodge Attitude]] [Mexico] made by Mitsubishi (Thailand)
|-
| ML5 || Kawasaki Motors Enterprise Co. Ltd. (Thailand)
|-
| MMA || Mitsubishi Motors (Thailand)
|-
| MMB || Mitsubishi Motors (Thailand)
|-
| MMC || Mitsubishi Motors (Thailand)
|-
| MMD || Mitsubishi Motors (Thailand)
|-
| MME || Mitsubishi Motors (Thailand)
|-
| MMF || BMW Manufacturing (Thailand) Co., Ltd.
|-
| MML || MG Thailand (SAIC-CP)
|-
| MMM || Chevrolet Thailand, Holden Colorado RC pickup
|-
| MMR || Subaru/Tan Chong Subaru Automotive (Thailand) Co. Ltd.
|-
| MMS || Suzuki Motor (Thailand) Co., Ltd. (passenger car)
|-
| MMT || Mitsubishi Motors (Thailand)
|-
| MMU || Holden Thailand (Colorado RG, Colorado 7, &amp; Trailblazer)
|-
| MM0, MM6, MM7, MM8 || Mazda Thailand (Ford-Mazda AutoAlliance Thailand plant)
|-
| MNA || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for Australia/New Zealand export
|-
| MNB || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for other right-hand drive markets
|-
| MNC || [[../Ford/VIN Codes|Ford]] Thailand (Ford-Mazda AutoAlliance Thailand plant) for left-hand drive markets
|-
| MNK || Hino Motors Manufacturing Thailand Co Ltd.
|-
| MNT || Nissan Motor (Thailand) Co., Ltd.
|-
| MNU || Great Wall Motor Manufacturing (Thailand) Co., Ltd.
|-
| MN3 || Eagle Vista [Canada] made by Mitsubishi (Thailand)
|-
| MPA || Isuzu Motors (Thailand) Co., Ltd. &amp; Holden Rodeo RA pickup made by Isuzu in Thailand
|-
| MPB || [[../Ford/VIN Codes|Ford]] Thailand (Ford Thailand Manufacturing plant)
|-
| MP1 || Isuzu Motors (Thailand) Co., Ltd.
|-
| MP2 || Mazda BT-50 pickup built by Isuzu Motors (Thailand) Co., Ltd.
|-
| MP3 || Plymouth Colt 100 [Canada] made by Mitsubishi (Thailand)
|-
| MP5 || Foton Motor Thailand
|-
| MRH || [[../Honda/VIN Codes|Honda]] Thailand (car)
|-
| MRT || Neta (Hozon Auto) made by Bangchan General Assembly Co., Ltd. 
|-
| MR0 || [[../Toyota/VIN Codes|Toyota]] Thailand (pickups &amp; Fortuner SUV)
|-
| MR1 || [[../Toyota/VIN Codes|Toyota]] Thailand
|-
| MR2 || [[../Toyota/VIN Codes|Toyota]] Thailand (Gateway plant) (passenger cars &amp; CUVs)
|-
| MR3 || [[../Toyota/VIN Codes|Toyota]] Thailand (Hilux Champ chassis cab)
|-
| MS0 || [[../SUPER SEVEN STARS MOTORS INDUSTRY CO.,LTD/VIN Codes|Super Seven Stars Motors]] Myanmar
|-
| MS1 || [[../SUPER SEVEN STARS AUTOMOTIVE CO.,LTD/VIN Codes|Super Seven Stars Automotive]] Myanmar
|-
| MS3 || Suzuki Myanmar Motor Co., Ltd.
|-
| MXB || Saryarka AvtoProm bus (Kazakhstan)
|-
| MXL || Yutong bus made by Qaz Tehna (Kazakhstan)
|-
| MXV || IMZ-Ural Ural Motorcycles (Kazakhstan)
|-
| MX3 || Hyundai Trans Auto (Kazakhstan)
|-
| NAA || Iran Khodro (Peugeot Iran)
|-
| NAC || Mammut (truck trailers)
|-
| NAD || Škoda
|-
| NAL || Maral Sanat Jarvid (truck trailers)
|-
| NAP || Pars Khodro
|-
| NAS || SAIPA
|-
| NC0 || Oghab Afshan (bus)
|-
| NC9/ || VIRA Diesel
|-
| ND9/345 || Oghab Afshan (bus)
|-
| NFB || Honda Atlas Cars Pakistan Ltd.
|-
| NG3 || Lucky Motor Corporation
|-
| NLA || Honda Turkiye A.S. cars
|-
| NLC || Askam Kamyon Imalat Ve Ticaret A.S.
|-
| NLE || Mercedes-Benz Türk A.S. Truck
|-
| NLF || Koluman Otomotiv Endustri A.S. (truck trailer)
|-
| NLH || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv car/SUV
|-
| NLJ || [[../Hyundai/VIN Codes|Hyundai]] Assan Otomotiv van
|-
| NLN || Karsan
|-
| NLR || Otokar
|-
| NLT || Temsa
|-
| NLZ || Tezeller
|-
| NL1 || TOGG
|-
| NL2 || HABAS/HBS (bus)
|-
| NMA || MAN Türkiye A.Ş.
|-
| NMB || Mercedes-Benz Türk A.S. Buses
|-
| NMC || BMC Otomotiv Sanayi ve Ticaret A.Ş.
|-
| NMH || Honda Anadolu motorcycle
|-
| NMS || Otoyol San. A.Ş.
|-
| NMT || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing Turkey
|-
| NM0 || Ford Otosan
|-
| NM1 || Oyak Renault Otomobil Fabrikaları A.Ş.
|-
| NM4 || Tofaş (Turk Otomobil Fabrikasi AS)
|-
| NNA || Anadolu Isuzu
|-
| NNN || Gépébus Oréos 4X (based on Otokar Vectio)
|-
| NNY || Yeksan (truck trailer)
|-
| NPM || Seyit Usta Treyler (truck trailer)
|-
| NPR || Oztreyler (truck trailer)
|-
| NPS || Nursan (truck trailer)
|-
| NP8|| ÖZGÜL TREYLER (truck trailer) 
|-
| NP9/002 || OKT Trailer (truck trailer) 
|-
| NP9/003 || Aksoylu Trailer (truck trailer) 
|-
| NP9/011 || Güleryüz (bus)
|-
| NP9/021 || Dogumak (truck trailer) 
|-
| NP9/022 || Alim (truck trailer) 
|-
| NP9/042 || Ali Rıza Usta (truck trailer) 
|-
| NP9/066 || Makinsan (truck trailer) 
|-
| NP9/093 || BRF Trailer (truck trailer) 
|-
| NP9/103 || Türkkar (bus)
|-
| NP9/106 || Çarsan Treyler (truck trailer) 
|-
| NP9/107 || Arbus Perfect (bus)
|-
| NP9/108 || Guven Makina (truck trailer) 
|-
| NP9/117 || Katmerciler (truck trailer) 
|-
| NP9/300 || TCV (bus) 
|-
| NP9/258 || Ceytrayler (truck trailer) 
|-
| NP9/306 || Cryocan (truck trailer) 
|-
| NRE || Bozankaya
|-
| NRX || Musoshi
|-
| NRY || Pilotcar Otomotiv
|-
| NR9/012 || Doğan Yıldız (truck trailer)
|-
| NR9/028 || Micansan (truck trailer)
|-
| NR9/029 || Yilteks (truck trailer)
|-
| NR9/034 || Akia (bus)
|-
| NR9/084 || Harsan (truck trailer)
|-
| NR9/257 || Vega Trailer (truck trailer)
|-
| NSA || SamAvto / SAZ (Uzbekistan)
|-
| NS2 || JV MAN Auto - Uzbekistan
|-
| NVA || Khazar (IKCO Dena made in Azerbaijan)
|- 
| PAB || Isuzu Philippines Corporation
|-
| PAD || Honda Cars Philippines
|-
| PE1 || Ford Motor Company Philippines
|-
| PE3 || Mazda Philippines made by Ford Motor Company Philippines
|-
| PFD || Hyundai Motor Group Innovation Center in Singapore (HMGICS)
|-
| PL1 || Proton, Malaysia
|-
| PL8 || Inokom-Hyundai
|-
| PLP || Subaru/Tan Chong Motor Assemblies, Malaysia
|-
| PLZ || Isuzu Malaysia
|-
| PMA || MAN Truck &amp; Bus Malaysia
|-
| PMH || Honda Malaysia (car)
|-
| PMK || Honda Boon Siew (motorcycle)
|-
| PML || Hicom 
|-
| PMN || Modenas
|-
| PMS || Suzuki Assemblers Malaysia (motorcycle)
|-
| PMV || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PMY || Hong Leong Yamaha Motor Sdn. Bhd.
|-
| PM1 || BMW &amp; Mini/Inokom
|-
| PM2 || Perodua
|-
| PM9/ || Bufori
|-
| PNA || Naza/Kia/Peugeot
|-
| PNA || Stellantis Gurun (Malaysia) Sdn. Bhd. (Peugeot)
|-
| PNS || SKSBUS Malaysia (bus)
|-
| PNS || TMSBUS Malaysia (bus)
|-
| PNV || Volvo Car Manufacturing Malaysia
|-
| PN1 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN2 || UMW Toyota Motor - Assembly Services Sdn. Bhd. (ASSB)
|-
| PN8 || Nissan/Tan Chong Motor Assemblies, Malaysia
|-
| PPP || Suzuki
|-
| PPV || Volkswagen/HICOM Automotive Manufacturers (Malaysia)
|-
| PP1 || Mazda/Inokom
|-
| PP3 || Hyundai/Inokom
|-
| PRA || Sinotruk
|-
| PRH || Chery (by Chery Alado Holdings [joint venture] at Oriental Assemblers plant)
|-
| PRX || Kia/Inokom
|-
| PR8 || Ford
|-
| PRN || GAC Trumpchi made by Warisan Tan Chong Automotif Malaysia
|-
| PV3 || Ford made by RMA Automotive Cambodia
|-
| RA1 || Steyr Trucks International FZE, UAE
|-
| RA9/015 || Al-Assri Industries (Trailers), UAE
|-
| LES || Isuzu MPV made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'91) (Taiwan)
|-
| LFA || Ford Lio Ho Motor Co Ltd. old designation (Taiwan)
|-
| LM1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LM4 || Tai Ling Motor Co Ltd. old designation (Suzuki ATV made by Tai Ling) (Taiwan)
|-
| LM5 || Isuzu Truck (Light Duty) made by Sanfu Motor Industrial Co., Ltd. (Trooper '87-'88) (Taiwan)
|-
| LN1 || Tai Ling Motor Co Ltd. old designation (Suzuki motorcycle made by Tai Ling) (Taiwan)
|-
| LPR || Yamaha Motor Taiwan Co. Ltd. old designation (Taiwan)
|-
| RFB || Kwang Yang Motor Co., Ltd. (Kymco), Taiwan
|-
| RFC || Taiwan Golden Bee
|-
| RFD || Tai Ling Motor Co Ltd. new designation (Taiwan)
|-
| RFG || Sanyang Motor Co., Ltd. (SYM) Taiwan
|-
| RFL || Her Chee Industrial Co., Ltd. (Adly), Taiwan
|-
| RFT || CPI Motor Company, Taiwan
|-
| RFV || Motive Power Industry Co., Ltd. (PGO Scooters including Genuine Scooter Company models made by PGO) (Taiwan)
|-
| RF3 || Aeon Motor Co., Ltd., Taiwan
|-
| RF5 || Yulon Motor Co. Ltd., Taiwan (Luxgen)
|-
| RF8 || EVT Technology Co., Ltd (motorcycle)
|-
| RGS || Kawasaki made by Kymco (Taiwan)
|-
| RHA || Ford Lio Ho Motor Co Ltd. new designation (Taiwan)
|-
| RKJ || Prince Motors Taiwan
|-
| RKL || Kuozui Motors (Toyota) (Taiwan)
|-
| RKM || China Motor Corporation (Taiwan)
|-
| RKR || Yamaha Motor Taiwan Co. Ltd. new designation
|-
| RKT || Access Motor Co., Ltd. (Taiwan)
|-
| RK3 || E-Ton Power Tech Co., Ltd. (motorcycle) (Taiwan)
|-
| RK3 || Honda Taiwan
|-
| RK7 || Kawasaki ATV made by Tai Ling Motor Co Ltd (rebadged Suzuki ATV) new designation (Taiwan)
|-
| RLA || Vina Star Motors Corp. – Mitsubishi (Vietnam)
|-
| RLC || Yamaha Motor Vietnam Co. Ltd.
|-
| RLE || Isuzu Vietnam Co.
|-
| RLH || Honda Vietnam Co. Ltd.
|-
| RLL || VinFast SUV
|-
| RLM || Mercedes-Benz Vietnam
|-
| RLN || VinFast
|-
| RLV || Vietnam Precision Industrial CO., Ltd. (Can-Am DS 70 &amp; DS 90)
|-
| RL0 || Ford Vietnam
|-
| RL4 || Toyota Motor Vietnam
|-
| RP8 || Piaggio Vietnam Co. Ltd.
|-
| RUN || Sollets-Auto ST6 (Russia)
|-
| R1J || Jiayuan Power (Hong Kong) Ltd. (Electric Low-Speed Vehicles) (Hong Kong)
|-
| R1N || Niu Technologies Group Ltd. (Hong Kong)
|-
| R10 || ZAP (HK) Co. Ltd.
|-
| R19/003 || GMI (bus) (Hong Kong)
|-
| R2P || Evoke Electric Motorcycles (Hong Kong)
|-
| R3M || Mangosteen Technology Co., Ltd. (Hong Kong)
|-
| R36 || HK Shansu Technology Co., Ltd. (Hong Kong)
|-
| R4N || Elyx Smart Technology Holdings (Hong Kong) Ltd.
|-
| R82 || Hangzhou Lantu Technology Co., Ltd. (Hong Kong)
|-
| SAA || Austin
|-
| SAB || Optare (1985-2020), Switch Mobility (2021-)
|-
| SAD || Daimler Company Limited (until April 1987)
|-
| SAD || Jaguar SUV (E-Pace, F-Pace, I-Pace)
|-
| SAF || ERF trucks
|-
| SAH || Honda made by Austin Rover Group
|-
| SAJ || Jaguar passenger car &amp; Daimler passenger car (after April 1987)
|-
| SAL || [[../Land Rover/VIN Codes|Land Rover]]
|-
| SAM || Morris
|-
| SAR || Rover &amp; MG Rover Group
|-
| SAT || Triumph car
|-
| SAX || Austin-Rover Group including Sterling Cars
|-
| SAY || Norton Motorcycles (UK) Ltd. (Donington Park/Donington Hall)
|-
| SAZ || Freight Rover
|-
| SA3 || Ginetta Cars
|-
| SA9/ || OX Global
|-
| SA9/A11 || Morgan Roadster (V6) (USA)
|-
| SA9/J00 || Morgan Aero 8 (USA)
|-
| SA9/004 || Morgan (4-wheel passenger cars)
|-
| SA9/005 || Panther
|-
| SA9/010 || Invicta S1
|-
| SA9/011 || Midas Cars
|-
| SA9/019 || TVR
|-
| SA9/022 || Triking Sports Cars
|-
| SA9/026 || Fleur de Lys
|-
| SA9/036 || Ginetta Cars
|-
| SA9/038 || DAX Cars
|-
| SA9/039 || Westfield Sportscars
|-
| SA9/048 || McLaren F1
|-
| SA9/050 || Marcos Engineering
|-
| SA9/062 || AC Cars (Brooklands Ace)
|-
| SA9/068 || Johnston Sweepers
|-
| SA9/073 || Tomita Auto UK (Tommykaira ZZ)
|-
| SA9/074 || Ascari 
|-
| SA9/088 || Spectre Angel 
|-
| SA9/105 || Mosler Europe Ltd.
|-
| SA9/113 || Noble
|-
| SA9/130 || MG Sport and Racing
|-
| SA9/141 || Wrightbus
|-
| SA9/202 || Morgan 3-Wheeler, Super 3
|-
| SA9/207 || Radical Sportscars
|-
| SA9/211 || BAC (Briggs Automotive Company Ltd.)
|-
| SA9/225 || Paneltex (truck trailer)
|-
| SA9/231 || Peel Engineering
|-
| SA9/337 || Ariel
|-
| SA9/341 || Zenos
|-
| SA9/438 || Charge Cars
|-
| SA9/458 || Gordon Murray Automotive
|-
| SA9/474 || Mellor (bus)
|-
| SA9/612 || Tiger Racing (kit car)
|-
| SA9/621 || AC Cars (Ace)
|-
| SBB || Leyland Vehicles
|-
| SBC || Iveco Ford Truck
|-
| SBF || Nugent (trailer)
|-
| SBJ || Leyland Bus
|-
| SBL || Leyland Motors &amp; Leyland DAF
|-
| SBM || McLaren
|-
| SBS || Scammell
|-
| SBU || United Trailers (truck trailer)
|-
| SBV || Kenworth &amp; Peterbilt [incomplete vehicle] made by Leyland Trucks
|-
| SBW || Weightlifter Bodies (truck trailer)
|-
| SB1 || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing UK
|-
| SCA || Rolls Royce passenger car
|-
| SCB || Bentley passenger car
|-
| SCC || Lotus Cars &amp; Opel Lotus Omega/Vauxhall Lotus Carlton
|-
| SCD || Reliant Motors
|-
| SCE || DeLorean Motor Cars N. Ireland (UK)
|-
| SCF || Aston Martin Lagonda Ltd. passenger car &amp; '21 DBX SUV
|-
| SCG || Triumph Engineering Co. Ltd. (original Triumph Motorcycle company)
|-
| SCK || Ifor Williams Trailers
|-
| SCM || Manitowoc Cranes - Grove
|-
| SCR || London Electric Vehicle Company &amp; London Taxi Company &amp; London Taxis International
|-
| SCV || Volvo Truck &amp; Bus Scotland
|-
| SC5 || Wrightbus (from ~2020)
|-
| SC6 || INEOS Automotive SUV
|-
| SDB || Talbot
|-
| SDC || SDC Trailers Ltd. (truck trailer)
|-
| SDF || Dodge Trucks – UK 1981–1984
|-
| SDG || Renault Trucks Industries 1985–1992
|-
| SDK || Caterham Cars
|-
| SDL || TVR
|-
| SDP || NAC MG UK &amp; MG Motor UK Ltd.
|-
| SDU || Utility (truck trailer)
|-
| SD7 || Aston Martin SUV
|-
| SD8 || Moke International Ltd.
|-
| SED || IBC Vehicles (General Motors Luton Plant) (Opel/Vauxhall, 1st gen. Holden Frontera, Isuzu Midi)
|-
| SEG || Dennis Eagle Ltd., including Renault Trucks Access and D Access
|-
| SEP || Don-Bur (truck trailer)
|-
| SEY || LDV Group Ltd.
|-
| SFA || [[../Ford/VIN Codes|Ford]] UK
|-
| SFD || Dennis UK / Alexander Dennis
|-
| SFE || Alexander Dennis UK
|-
| SFR || Fruehauf (truck trailer)
|-
| SFN || Foden Trucks &amp; Kenworth [truck] made by Foden Trucks
|-
| SFZ || Tesla Roadster made by Lotus
|-
| SGA || Avondale (caravans)
|-
| SGB || Bailey (caravans)
|-
| SGD || Swift Group Ltd. (caravans)
|-
| SGE || Elddis (caravans)
|-
| SGL || Lunar Caravans Ltd.
|-
| SG4 || Coachman Caravan Co. Ltd.
|-
| SG7 || ABI Caravans Ltd.
|-
| SHH || [[../Honda/VIN Codes|Honda]] UK passenger car
|-
| SHS || [[../Honda/VIN Codes|Honda]] UK SUV
|-
| SH2 || The Norton Motorcycle Co., Ltd. (TVS Motor Co. subsidiary)
|-
| SH7 || INEOS Automotive truck
|-
| SJA || Bentley SUV
|-
| SJB || Brian James Trailers Ltd
|-
| SJK || Nissan Motor Manufacturing UK - Infiniti
|-
| SJN || Nissan Motor Manufacturing UK - Nissan
|-
| SJ1 || Ree Automotive
|-
| SKA || Vauxhall
|-
| SKB || Kel-Berg Trailers &amp; Trucks
|-
| SKF || Bedford Vehicles
|-
| SKL || Anaig (UK) Technology Ltd
|-
| SKM || King Military Engineering Ltd.
|-
| SLA || Rolls Royce SUV
|-
| SLC || Thwaites Dumpers
|-
| SLG || McMurtry Automotive
|-
| SLN || Niftylift
|-
| SLP || JC Bamford Excavators Ltd.
|-
| SLV || Volvo bus
|-
| SMR || Montracon (truck trailer)
|-
| SMT || Triumph Motorcycles Ltd. (current Triumph Motorcycle company)
|-
| SMW || Cartwright (truck trailer)
|-
| SMX || Gray &amp; Adams (truck trailer)
|-
| SNE || Barkas (East Germany)
|-
| SNE || Wartburg (East Germany)
|-
| SNT || Trabant (East Germany)
|-
| SNZ || MZ (motorcycle) (Germany)
|-
| SPE || B-ON GmbH (Germany)
|-
| ST3 || Calabrese (truck trailer)
|-
| SUA || Autosan (bus)
|-
| SUB || Tramp Trail (trailer)
|-
| SUC || Wiola (trailer)
|-
| SUD || Wielton (truck trailers)
|-
| SUF || FSM/Fiat Auto Poland (Polski Fiat)
|-
| SUG || Mega Trailers (truck trailer) (Poland)
|-
| SUJ || Jelcz (Poland)
|-
| SUL || FSC (Poland)
|-
| SUM || Novatrail (truck trailers)
|-
| SUP || FSO/Daewoo-FSO (Poland)
|-
| SUU || Solaris Bus &amp; Coach (Poland)
|-
| SU9/AR1 || Emtech (truck trailer)
|-
| SU9/BU1 || BODEX (truck trailer)
|-
| SU9/DE2 || Demarco (truck trailer)
|-
| SU9/EB1 || Elbo (truck trailer)
|-
| SU9/EZ1 || Enerco (truck trailer)
|-
| SU9/NC5 || Zasta (truck trailer)
|-
| SU9/NJ1 || Janmil (truck trailer)
|-
| SU9/PL1 || Plandex (truck trailer)
|-
| SU9/PN1 || Solaris Bus &amp; Coach (Poland) - until 2004
|-
| SU9/RE1 || Redos (truck trailer)
|-
| SU9/RE2 || Gromex (trailer)
|-
| SU9/TR1 || Plavec (truck trailer)
|-
| SU9/YV1 || Pilea bus/ARP E-Vehicles (Poland)
|-
| SU9/ZC1 || Wolf (truck trailer)
|-
| SVH || ZASŁAW (truck trailer)
|-
| SVM || Inter Cars (truck trailer)
|-
| SVS || BODEX (truck trailer)
|-
| SV9/BC2 || BC-LDS (truck trailer)
|-
| SV9/DR1 || Dromech (truck trailer)
|-
| SV9/RN1 || Prod-Rent (truck trailer)
|-
| SWH || Temared (trailers)
|-
| SWR || Weekend Trailers (trailers)
|-
| SWV || TA-NO (Poland)
|-
| SWZ || Zremb (trailers)
|-
| SW9/BA1 || Solbus
|-
| SW9/WG3 || Grew / Opalenica (trailer)
|-
| SXE || Neptun Trailers
|-
| SXK || Konar (truck trailer)
|-
| SXM || MELEX Sp. z o.o.
|-
| SXY || Wecon (truck trailer)
|-
| SXX || Martz (trailer)
|-
| SX7 || Arthur Bus
|-
| SX9/GR0 || GRAS (truck trailer)
|-
| SX9/KT1 || AMZ - Kutno (bus)
|-
| SX9/PN1 || Polkon (truck trailer)
|-
| SX9/SP1 || SOMMER Polska (truck trailer)
|-
| SYB || Rydwan (trailer)
|-
| SYG || Gniotpol, GT Trailers Sp. z o. o. (truck trailer)
|-
| SY1 || Neso Bus (PAK-PCE Polski Autobus Wodorowy)
|-
| SY9/FR1 || Feber (truck trailer)
|-
| SY9/PF1 || KEMPF (truck trailer)
|-
| SZA || Scania Poland
|-
| SZC || Vectrix (motorcycle)
|-
| SZL || Boro Trailers
|-
| SZN || Przyczepy Głowacz (trailer) 
|-
| SZR || Niewiadów (trailer) 
|-
| SZ9/AE6 || Gewe (trailer) 
|-
| SZ9/BG1 || GALA Syriusz (trailer) 
|-
| SZ9/PW1 || PRO-WAM (truck trailer)
|-
| SZ9/TU1 || Ovibos (truck trailer)
|-
| S19/AM0 || AMO Plant (bus) (Latvia)
|-
| S19/EF1 || Electrify (minibus) (Latvia)
|-
| S19/MT0 || Mono-Transserviss (truck trailer) (Latvia)
|-
| TAW || NAW Nutzfahrzeuggesellschaft Arbon &amp; Wetzikon AG (Switzerland)
|-
| TBS || Boschung AG (Switzerland)
|-
| TCC || Micro Compact Car AG (smart 1998-1999) (Switzerland)
|-
| TDM || QUANTYA Swiss Electric Movement (Switzerland)
|-
| TEB || Bucher Municipal AG (includes Johnston Sweepers) (Switzerland)
|-
| TEM || Twike (SwissLEM AG) (Switzerland)
|-
| TFH || FHS Frech-Hoch AG (truck trailer) (Switzerland)
|-
| TH9/512 || Hess AG (bus, trolleybus) (Switzerland)
|-
| TJ5 || Vezeko (trailer) (Czech Republic)
|-
| TKP || Panav a.s.  (truck trailer) (Czech Republic)
|-
| TKX || Agados s.r.o. (trailer) (Czech Republic)
|-
| TKY || Metaco (truck trailer) (Czech Republic)
|-
| TK9/AH3 || Atmos Chrást s.r.o. (Czech Republic)
|-
| TK9/AP3 || Agados, spol. s.r.o. (trailer) (Czech Republic)
|-
| TK9/HP1 || Hipocar (truck trailer) (Czech Republic)
|-
| TK9/PP7 || Paragan Trucks (truck trailer) (Czech Republic)
|-
| TK9/SL5 || SOR Libchavy buses (Czech Republic)
|-
| TK9/SS5 || SVAN Chrudim (truck trailer) (Czech Republic)
|-
| TLJ || Jawa Moto (Czech Republic)
|-
| TMA || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech
|-
| TMB || Škoda Auto|Škoda (Czech Republic)
|-
| TMC || [[../Hyundai/VIN Codes|Hyundai]] Motor Manufacturing Czech (SUV)
|-
| TMK || Karosa (Czech Republic)
|-
| TMP || Škoda trolleybuses (Czech Republic)
|-
| TMT || Tatra passenger car (Czech Republic)
|-
| TM9/CA2 || Oasa bus (Oprava a stavba automobilů) (Czech Republic)
|-
| TM9/SE3 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/SE4 || Škoda Transportation trolleybuses (Czech Republic)
|-
| TM9/TE6 || TEDOM bus (Czech Republic)
|-
| TNA || Avia/Daewoo Avia
|-
| TNE || TAZ
|-
| TNG || LIAZ (Liberecké Automobilové Závody)
|-
| TNT || Tatra trucks
|-
| TNU || Tatra trucks
|-
| TN9/EE7 || Ekova (bus) (Czech Republic)
|-
| TN9/VP5 || VPS (truck trailer)
|-
| TRA || Ikarus Bus
|-
| TRC || Csepel bus
|-
| TRE || Rákos bus
|-
| TRK || Credo bus/Kravtex (Hungary)
|-
| TRR || Rába Bus (Hungary)
|-
| TRU || Audi Hungary (TT/TTS, '12-'13 TT RS)
|-
| TSB || Ikarus Bus
|-
| TSC || VIN assigned by the National Transport Authority of Hungary
|-
| TSE || Ikarus Egyedi Autobuszgyar (EAG) (Hungary)
|-
| TSF || Alfabusz (Hungary)
|-
| TSM || Suzuki Hungary (Magyar Suzuki),&lt;br&gt; Fiat Sedici made by Suzuki, Subaru Justy G3X made by Suzuki, Suzuki Swace made by Toyota UK (TMUK)
|-
| TSY || Keeway Motorcycles (Hungary)
|-
| TS9/111 || NABI Autóbuszipari (bus) (Hungary)
|-
| TS9/130 || Enterprise Bus (Hungary)
|-
| TS9/131 || MJT bus (Hungary)
|-
| TS9/156 || Ikarus / ARC (Auto Rad Controlle Kft.) bus (Hungary)
|-
| TS9/167 || Hungarian Bus Kft. (Hungary)
|-
| TS9/170 || Csaba Metál bus (Hungary)
|-
| TT9/117 || Ikarus Egyedi Autobusz Gyarto Kft. / Magyar Autóbuszgyártó Kft. / MABI (Hungary)
|-
| TT9/123 || Ikarus Global Zrt. (Hungary)
|-
| TWG || CaetanoBus (Portugal)
|-
| TW0 || CaetanoBus (Portugal)
|-
| TW1 || Toyota Caetano Portugal, S.A. (Toyota Coaster, Dyna, Optimo, Land Cruiser 70 Series)
|-
| TW2 || [[../Ford/VIN Codes|Ford]] Lusitana (Portugal)
|-
| TW4 || UMM (Portugal)
|-
| TW6 || Citroën (Portugal)
|-
| TW7 || Mini Moke made by British Leyland &amp; Austin Rover Portugal
|-
| TX5 || Mini Moke made by Cagiva (Moke Automobili)
|-
| TX9/046 || Riotrailer (truck trailer) (Portugal)
|-
| TYA || Mitsubishi Fuso Truck and Bus Corp. Portugal (right-hand drive)
|-
| TYB || Mitsubishi Fuso Truck and Bus Corp. Portugal (left-hand drive)
|-
| T3C || Lohr Backa Topola (truck trailer) (Serbia)
|-
| T49/BG7 || FAP (Serbia)
|-
| T49/BH8 || Megabus (bus) (Serbia)
|-
| T49/BM2 || Feniksbus (minibus) (Serbia)
|-
| T49/V16 || MAZ made by BIK (bus) (Serbia)
|-
| T7A || Ebusco (Netherlands)
|-
| UA1 || AUSA Center (Spain)
|-
| UA2 || Iveco Massif &amp; Campagnola made by Santana Motors in Spain
|-
| UA4 || Irizar e-mobility (Spain)
|-
| UCY || Silence Urban Ecomobility (Spain)
|-
| UD3 || Granalu truck trailers (Belgium)
|-
| UHE || Scanvogn (trailer) (Denmark)
|-
| UHL || Camp-let (recreational vehicle) (Denmark)
|-
| UH2 || Brenderup (trailer) (Denmark)
|-
| UH2 || De Forenede Trailerfabrikke (trailer) (Denmark)
|-
| UH9/DA3 || DAB - Danish Automobile Building (acquired by Scania) (Denmark)
|-
| UH9/FK1 || Dapa Trailer (truck trailer) (Denmark)
|-
| UH9/HF1 || HFR Trailer A/S (truck trailer) (Denmark)
|-
| UH9/HM1 || HMK Bilcon A/S (truck trailer) (Denmark)
|-
| UH9/NS1 || Nopa (truck trailer) (Denmark)
|-
| UH9/NT1 || Nordic Trailer (truck trailer) (Denmark)
|-
| UH9/VM2 || VM Tarm a/s (truck trailer) (Denmark)
|-
| UJG || Garia ApS - Club Car (Denmark)
|-
| UKR || Hero Camper (Denmark)
|-
| UMT || MTDK a/s (truck trailer) (Denmark)
|-
| UN1 || [[../Ford/VIN Codes|Ford]] Ireland
|-
| UN9/089 || Brian Noone Ltd. bus (Ireland)
|-
| UU1 || Dacia (Romania)
|-
| UU2 || Oltcit
|-
| UU3 || ARO
|-
| UU4 || Roman/Grivbuz
|-
| UU5 || Rocar
|-
| UU6 || Daewoo Romania
|-
| UU7 || Euro Bus Diamond
|-
| UU9 || Astra Bus
|-
| UVW || UMM (truck trailer)
|-
| UV9/AT1 || ATP Trucks, ATP Bus
|-
| UWR || Robus Reșița
|-
| UZT || UTB (Uzina de Tractoare Brașov)
|-
| U1A || Sanos (North Macedonia)
|-
| U1V || VDL Van Hool Macedonia (North Macedonia)
|-
| U5Y || Kia Motors Slovakia
|-
| U59/AS0 || ASKO (truck trailer)
|-
| U6A || Granus (bus) (Slovakia)
|-
| U6Y || Kia Motors Slovakia
|-
| U69/NL1 || Novoplan (bus) (Slovakia)
|-
| U69/SB1 || SlovBus (bus)
|-
| U69/TR8 || Troliga Bus (Slovakia)
|-
| VAG || Steyr-Daimler-Puch Puch G &amp; Steyr-Puch Pinzgauer
|-
| VAH || Hangler (truck trailer)
|-
| VAK || Kässbohrer Transport Technik
|-
| VAN || MAN Austria/Steyr-Daimler-Puch Steyr Trucks
|-
| VAV || Schwarzmüller
|-
| VAX || Schwingenschlogel (truck trailer)
|-
| VA0 || ÖAF, Gräf &amp; Stift
|-
| VA4 || KSR Group (motorcycle)
|-
| VA9/GS0 || Gsodam Fahrzeugbau (truck trailer)
|-
| VA9/RB1 || Rosenbauer International AG (truck)
|-
| VA9/ZT0 || Berger Fahrzeugtechnik (truck trailer)
|-
| VBF || Fit-Zel (trailer)
|-
| VBK || KTM 
|-
| VBK || Husqvarna Motorcycles &amp; Gas Gas under KTM ownership
|-
| VCF || Fisker Inc. (Fisker Ocean) made by Magna Steyr
|-
| VFA || Alpine (A310, A610, A110, A390), Renault Alpine GTA
|-
| VFG || Caravelair (caravans)
|-
| VFK || Fruehauf (truck trailers)
|-
| VFN || Trailor, General Trailers (truck trailers)
|-
| VF1 || Renault, Renault GTA '87-'90 (UK market Alpine GTA), Mobilize Duo, Eagle Medallion made by Renault,&lt;br&gt; Opel/Vauxhall Arena made by Renault, Mitsubishi ASX, Colt, Grandis, &amp; Eclipse Cross EV made by Renault
|-
| VF2 || Renault Trucks
|-
| VF3 || Peugeot
|-
| VF4 || Talbot
|-
| VF5 || Iveco Unic
|-
| VF6 || Renault Trucks including vans made by Renault S.A. &amp; Maxity truck made by Nissan Motor Ibérica S.A.
|-
| VF7 || Citroën
|-
| VF8 || Matra Automobiles (Talbot-Matra Murena, Rancho made by Matra, Renault Espace I/II/III, Avantime made by Matra)
|-
| VF9/024 || Legras Industries (truck trailer)
|-
| VF9/045 || Nardeau SAS (truck trailer)
|-
| VF9/049 || G. Magyar (truck trailer)
|-
| VF9/063 || Maisonneuve (truck trailer)
|-
| VF9/132 || Jean CHEREAU S.A.S. (truck trailer)
|-
| VF9/300 || EvoBus France
|-
| VF9/435 || Merceron (truck trailer)
|-
| VF9/519 || Hommell 
|-
| VF9/607 || Mathieu (sweeper)
|-
| VF9/673 || Venturi Automobiles
|-
| VF9/795 || [[../Bugatti/VIN Codes|Bugatti Automobiles S.A.S.]]
|-
| VF9/848 || G. Magyar (truck trailer)
|-
| VF9/880 || Bolloré Bluebus
|-
| VF9/938 || SAFRA (bus)
|-
| VGA || Peugeot Motocycles
|-
| VGT || ASCA (truck trailers)
|-
| VGU || Trouillet (truck trailers)
|-
| VGW || BSLT (truck trailers)
|-
| VGX || Coder (truck trailers)
|-
| VGY || Lohr (truck trailers)
|-
| VG5 || MBK (motorcycles) &amp; Yamaha Motor
|-
| VG6 || Renault Trucks &amp; Mack Trucks medium duty trucks made by Renault Trucks
|-
| VG7 || Renault Trucks
|-
| VG8 || Renault Trucks
|-
| VG9/019 || Naya (autonomous vehicle)
|-
| VG9/061 || Alstom-NTL Aptis (bus)
|-
| VHR || Robuste (truck trailer)
|-
| VHX || Manitowoc Cranes - Potain
|-
| VH1 || Benalu SAS (truck trailer)
|-
| VH8 || Microcar
|-
| VJR || Ligier
|-
| VJY || Gruau
|-
| VJ1 || Heuliez Bus
|-
| VJ2 || Mia Electric
|-
| VJ4 || Gruau
|-
| VKD || Cheval Liberté (horse trailer)
|-
| VK1 || SEG (truck trailer)
|-
| VK2 || Grandin Automobiles
|-
| VK8 || Venturi Automobiles
|-
| VLG || Aixam-Mega
|-
| VLU || Scania France
|-
| VL4 || Bluecar, Citroen E-Mehari
|-
| VMK || Renault Sport Spider
|-
| VMS || Automobiles Chatenet
|-
| VMT || SECMA
|-
| VMW || Gépébus Oréos 55
|-
| VM3 || Lamberet (trailer)
|-
| VM3 || Chereau (truck trailer)
|-
| VN1 || Renault SOVAB (France), Opel/Vauxhall Movano A made at SOVAB
|-
| VN4 || Voxan
|-
| VNB || Sherco Motorcycles SARL
|-
| VNE || Iveco Bus/Irisbus (France)
|-
| VNK || [[../Toyota/VIN Codes|Toyota]] Motor Manufacturing France &amp; '11-'13 Daihatsu Charade (XP90) made by TMMF
|-
| VNV || Nissan made in France by Renault
|-
| VPG || MPM Motors 
|-
| VPL || Nosmoke S.A.S
|-
| VP3 || G. Magyar (truck trailers)
|-
| VRW || Goupil
|-
| VR1 || DS Automobiles
|-
| VR3 || Peugeot (under Stellantis)
|-
| VR7 || Citroën (under Stellantis)
|-
| VSA || Mercedes-Benz Spain
|-
| VSC || Talbot
|-
| VSE || Santana Motors (Land Rover Series-based models) &amp; Suzuki SJ/Samurai, Jimny, &amp; Vitara made by Santana Motors in Spain
|-
| VSF || Santana Motors (Anibal/PS-10, 300/350)
|-
| VSK || Nissan Motor Iberica SA, Nissan passenger car/MPV/van/SUV/pickup &amp; Ford Maverick 1993–1999
|-
| VSR || Leciñena (truck trailers)
|-
| VSS || SEAT/Cupra
|-
| VSX || Opel Spain
|-
| VSY || Renault V.I. Spain (bus)
|-
| VS1 || Pegaso
|-
| VS5 || Renault Spain
|-
| VS6 || [[../Ford/VIN Codes|Ford]] Spain
|-
| VS7 || Citroën Spain
|-
| VS8 || Peugeot Spain
|-
| VS9/001 || Setra Seida (Spain)
|-
| VS9/011 || Advanced Design Tramontana
|-
| VS9/013 || Mirofret (truck trailer) (Spain)
|-
| VS9/016 || Irizar bus (Spain)
|-
| VS9/019 || Cobos Hermanos (truck trailer) (Spain)
|-
| VS9/031 || Carrocerias Ayats (Spain)
|-
| VS9/032 || Parcisa (truck trailer) (Spain)
|-
| VS9/044 || Beulas bus (Spain) (Spain)
|-
| VS9/047 || Indox (truck trailers) (Spain)
|-
| VS9/052 || Montull (truck trailer) (Spain)
|-
| VS9/057 || SOR Ibérica (truck trailers) (Spain)
|-
| VS9/072 || Mecanicas Silva (truck trailer) (Spain)
|-
| VS9/098 || Sunsundegui bus (Spain)
|-
| VS9/172 || EvoBus Iberica 
|-
| VS9/917 || Nogebus (Spain)
|-
| VTD || Montesa Honda (Honda Montesa motorcycle models)
|-
| VTH || Derbi (motorcycles)
|-
| VTL || Yamaha Spain (motorcycles)
|-
| VTM || Montesa Honda (Honda motorcycle models)
|-
| VTP || Rieju S.A. (motorcycles)
|-
| VTR || Gas Gas
|-
| VTT || Suzuki Spain (motorcycles)
|-
| VVC || SOR Ibérica (truck trailers)
|-
| VVG || Tisvol (truck trailers)
|-
| VV1 || Lecitrailer Group (truck trailers)
|-
| VV5 || Prim-Ball (truck trailers)
|-
| VV9/ || [[wikipedia:Tauro Sport Auto|TAURO]] Sport Auto Spain
|-
| VV9/010 || Castrosúa bus (Spain)
|-
| VV9/125 || Indetruck (truck trailers)
|-
| VV9/130 || Vectia Mobility bus (Spain)
|-
| VV9/130 || UNVI bus (Spain)
|-
| VV9/359|| Hispano-Suiza
|-
| VWA || Nissan Vehiculos Industriales SA, Nissan Commercial Vehicles
|-
| VWF || Guillén Group (truck trailers)
|-
| VWL || Indox (truck trailers)
|-
| VWV || Volkswagen Spain
|-
| VXE || Opel Automobile Gmbh/Vauxhall van
|-
| VXF || Fiat van (Fiat Scudo, Ulysse '22-)
|-
| VXK || Opel Automobile Gmbh/Vauxhall car/SUV
|-
| VXY || Neobus a.d. (Serbia)
|-
| VX1 || [[w:Zastava Automobiles|Zastava Automobiles]] / [[w:Yugo|Yugo]] (Yugoslavia/Serbia)
|-
| VYC || Lancia Ypsilon (4th gen.)
|-
| VYE || Jeep Compass (3rd gen. - EU market '26-)
|-
| VYF || Fiat Doblo '23- &amp; Fiat Topolino '23- &amp; Fiat Grande Panda '25-
|-
| VYJ || Ram 1200 '25- (sold in Mexico)
|-
| VYS || Renault &amp; Alpine made by Ampere (Renault 5 E-Tech, Renault 4 E-Tech, Alpine A290)
|-
| VZ2 || Avtomontaža (bus) (Slovenia)
|-
| V1Y || FAS Sanos bus (Yugoslavia/North Macedonia)
|-
| V2X || Ikarbus a.d. (Serbia)
|-
| V31 || Tvornica Autobusa Zagreb (TAZ) (Croatia)
|-
| V34 || Crobus bus (Croatia)
|-
| V39/AB8 || Rimac Automobili (Croatia)
|-
| V39/CB3 || Eurobus (Croatia)
|-
| V39/WB4 || Rasco (machinery) (Croatia)
|-
| V6A || Bestnet AS; Tiki trailers (Estonia)
|-
| V6B || Brentex-Trailer (Estonia)
|-
| V6T || Verge Motorcycles (Estonia)
|-
| V61 || Respo Trailers (Estonia)
|-
| WAC || Arge Audi Porsche (Audi/Porsche RS2 Avant)
|-
| WAF || Ackermann (truck trailer)
|-
| WAG || Neoplan
|-
| WAP || Alpina
|-
| WAU || Audi car
|-
| WA1 || Audi SUV
|-
| WBA || BMW car
|-
| WBC || Boom Trikes
|-
| WBJ || Bitter Cars
|-
| WBK || Böcker Maschinenwerke GmbH 
|-
| WBL || Blumhardt (truck trailers)
|-
| WBS || BMW M car
|-
| WBU || Bürstner (caravans)
|-
| WBX || BMW SUV
|-
| WBY || BMW i car
|-
| WB0 || Böckmann Fahrzeugwerke GmbH (trailers)
|-
| WB1 || BMW Motorrad 
|-
| WB2 || Blyss (trailer)
|-
| WB3 || BMW Motorrad Motorcycles made in India by TVS
|-
| WB4 || BMW Motorrad Motorscooters made in China by Loncin
|-
| WB5 || BMW i SUV
|-
| WCD || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2019
|-
| WCM || Wilcox (truck trailer)
|-
| WDA || Mercedes-Benz incomplete vehicle (North America)
|-
| WDB || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] &amp; Maybach
|-
| WDC || Mercedes-Benz SUV
|-
| WDD || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] car
|-
| WDF || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] van/pickup (French &amp; Spanish built models – Citan &amp; Vito &amp; X-Class)
|-
| WDP || Freightliner Sprinter incomplete vehicle 2005–2019
|-
| WDR || Freightliner Sprinter MPV (van with 2 or 3 rows of seats) 2005–2019
|-
| WDT || Dethleffs (caravans)
|-
| WDW || Dodge Sprinter &quot;bus&quot; (van with more than 3 rows of seats) 2008–2009
|-
| WDX || Dodge Sprinter incomplete vehicle 2005–2009
|-
| WDY || Freightliner Sprinter truck (cargo van with 1 row of seats) 2005–2019
|-
| WDZ || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| WD0 || Dodge Sprinter truck (cargo van with 1 row of seats) 2005–2009
|-
| WD1 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 incomplete vehicle
|-
| WD2 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 truck (cargo van with 1 row of seats)
|-
| WD3 || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| WD4 || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| WD5 || Freightliner Sprinter 2002 &amp; Sprinter (Dodge or Freightliner) 2003–2005 MPV (van with 2 or 3 rows of seats)
|-
| WD6 || Freightliner Unimog truck
|-
| WD7 || Freightliner Unimog incomplete vehicle
|-
| WD8 || Dodge Sprinter MPV (van with 2 or 3 rows of seats) 2005–2009
|-
| WEB || Evobus GmbH (Mercedes-Benz buses)
|-
| WEG || Ablinger  (trailer)
|-
| WEL || e.GO Mobile AG
|-
| WFB || Feldbinder Spezialfahrzeugwerke GmbH
|-
| WFC || Fendt (caravans)
|-
| WFD || Fliegl Trailer
|-
| WFN || Tadano Faun GmbH
|-
| WF0 || [[../Ford/VIN Codes|Ford]] Germany
|-
| WF1 || Merkur
|-
| WGB || Göppel Bus GmbH
|-
| WG0 || Goldhofer AG (truck trailer)
|-
| WHB || Hobby - Wohnwagenwerk, Ing. H. Striewski GmbH (recreational vehicles)
|-
| WHD || Humbaur GmbH (truck trailer)
|-
| WHL || Hulco (trailer)
|-
| WHW || Hako GmbH
|-
| WHY || Hymer GmbH &amp; Co. KG (recreational vehicles)
|-
| WH7 || Hüfferman (truck trailer)
|-
| WJM || Iveco/Iveco Magirus
|-
| WJR || Irmscher
|-
| WKE || Krone (truck trailers)
|-
| WKK || Setra (Evobus GmbH; formerly Kässbohrer)
|-
| WKN || Knaus, Weinsberg (caravans)
|-
| WKV || Kässbohrer Fahrzeugwerke Gmbh (truck trailers)
|-
| WK0 || Kögel (truck trailers)
|-
| WLA || Langendorf semi-trailers
|-
| WLF || Liebherr (mobile crane)
|-
| WMA || MAN Truck &amp; Bus 
|-
| WME || smart (from 5/99)
|-
| WMG || Demag Cranes
|-
| WMM || Karl Müller GmbH &amp; Co. KG (truck trailers)
|-
| WMP || M &amp; V GmbH (truck trailers)
|-
| WMU || Hako GmbH (Multicar)
|-
| WMW || MINI car
|-
| WMX || Mercedes-AMG used for Mercedes-Benz SLS AMG &amp; Mercedes-AMG GT &amp; Mercedes-AMG One (not used in North America)
|-
| WMZ || MINI SUV
|-
| WNA || Next.e.GO Mobile SE
|-
| WP0 || Porsche car
|-
| WP1 || Porsche SUV
|-
| WRA || Renders (truck trailers)
|-
| WRJ || Riese &amp; Müller (bicycle)
|-
| WSE || STEMA Metalleichtbau GmbH (trailers)
|-
| WSJ || STERK Trailers (truck trailers)
|-
| WSK || Schmitz-Cargobull Gotha (truck trailers)
|-
| WSM || Schmitz-Cargobull (truck trailers)
|-
| WSP || Spitzer (truck trailers)
|-
| WSV || Aebi Schmidt Group
|-
| WS5 || StreetScooter
|-
| WS7 || Sono Motors
|-
| WTA || Tabbert (caravans)
|-
| WUA || Audi Sport GmbH (formerly quattro GmbH) car &lt;br&gt; (includes '04-'09 S4 Cabriolet &amp; '06 S4 25quattro Special Edition sedan &amp; '16-'18 S8 Plus &amp; non-North American mkt. Q7 V12 TDI)
|-
| WU1 || Audi Sport GmbH (formerly quattro GmbH) SUV
|-
| WVG || Volkswagen SUV &amp; Touran &amp; N. American mkt. ID Buzz '25
|-
| WVM || Arbeitsgemeinschaft VW-MAN
|-
| WVP || Viseon Bus
|-
| WVW || Volkswagen passenger car, Sharan, Golf Plus, Golf Sportsvan
|-
| WV1 || Volkswagen Commercial Vehicles (cargo van or 1st gen. Amarok)
|-
| WV2 || Volkswagen Commercial Vehicles (passenger van or minibus)
|-
| WV3 || Volkswagen Commercial Vehicles (incomplete vehicle: chassis cab/cutaway)&lt;br&gt; [includes Winnebago Rialta ('97-'04), Winnebago Vista ('02-'04), Itasca Sunstar ('02-'04)]
|-
| WV4 || Volkswagen Commercial Vehicles (2nd gen. Amarok &amp; T7 Transporter made by Ford)
|-
| WV5 || Volkswagen Commercial Vehicles (T7 Caravelle made by Ford)
|-
| WWA || Wachenhut (truck trailer)
|-
| WWC || WM Meyer (truck trailer)
|-
| WZ1 || Toyota Supra (Fifth generation for North America)
|-
| W0D || Obermaier (truck trailer)
|-
| W0L || Adam Opel AG/Vauxhall &amp; Holden
|-
| W0L || Holden Zafira &amp; Subaru Traviq made by GM Thailand
|-
| W0V || Opel Automobile Gmbh/Vauxhall &amp; Holden (since 2017)
|-
| W04 || Buick Regal &amp; Buick Cascada
|-
| W06 || Cadillac Catera
|-
| W08 || Saturn Astra
|-
| W09/A55 || Artega Automobile
|-
| W09/A71 || Apollo
|-
| W09/B09 || Bitter Cars
|-
| W09/B16 || Brabus
|-
| W09/B48 || Bultmann (trailer)
|-
| W09/B91 || Boerner (truck trailer)
|-
| W09/C09 || Carnehl Fahrzeugbau (truck trailer)
|-
| W09/D04 || DOLL (truck trailer)
|-
| W09/D05 || Drögmöller (bus)
|-
| W09/D17 || Dinkel (truck trailer)
|-
| W09/E04 || Eder (trailer)
|-
| W09/E27 || Esterer (truck trailer)
|-
| W09/E32 || ES-GE (truck trailer)
|-
| W09/E45 || Eurotank (truck trailer)
|-
| W09/F46 || FSN Fahrzeugbau (truck trailer)
|-
| W09/F57 || Twike
|-
| W09/G10 || GOFA (truck trailer)
|-
| W09/G64 || Gumpert
|-
| W09/H10 || Heitling Fahrzeugbau
|-
| W09/H21|| Dietrich Hisle GmbH (truck trailer)
|-
| W09/H46 || Hendricks (truck trailer)
|-
| W09/H49 || H&amp;W Nutzfahrzeugtechnik GmbH (truck trailer)
|-
| W09/J02 || Isdera
|-
| W09/K27 || Krupp
|-
| W09/K27 || Kotschenreuther (truck trailer)
|-
| W09/L05 || Liebherr
|-
| W09/L06 || LMC Caravan (recreational vehicles)
|-
| W09/M08 || MEILLER Kipper (truck trailer)
|-
| W09/M09 || Meierling (truck trailer)
|-
| W09/M29 || MAFA (truck trailer)
|-
| W09/M40 || Franz Mersch (trailer)
|-
| W09/M79 || MKF Matallbau (truck trailer)
|-
| W09/N22 || NFP-Eurotrailer (truck trailer)
|-
| W09/P13 || Pagenkopf (truck trailer)
|-
| W09/P72 || De Tomaso Automobili (Capricorn)
|-
| W09/R06 || RUF
|-
| W09/R14 || Rancke (truck trailer)
|-
| W09/R27 || Gebr. Recker Fahrzeugbau (truck trailer)
|-
| W09/R30 || Reisch (truck trailer)
|-
| W09/R38 || Rewaco
|-
| W09/SG0 || Sileo (bus)
|-
| W09/SG1 || SEKA (truck trailer)
|-
| W09/S24 || Sommer (truck trailer)
|-
| W09/S25 || Spermann (truck trailer)
|-
| W09/S27 || Schröder (truck trailer)
|-
| W09/W11 || Wilken (truck trailer)
|-
| W09/W14 || Weka (truck trailer)
|-
| W09/W16 || Wellmeyer (truck trailer)
|-
| W09/W20 || Kurt Willig GmbH &amp; Co. KG  (truck trailer)
|-
| W09/W29 || Wiese (truck trailer)
|-
| W09/W35 || Wecon GmbH  (truck trailer)
|-
| W09/W46 || WT-Metall (trailer)
|-
| W09/W59 || Wiesmann
|-
| W09/W70 || Wüllhorst (truck trailer)
|-
| W09/W86 || Web Trailer GmbH  (truck trailer)
|-
| W09/004 || ORTEN Fahrzeugbau (truck trailer)
|-
| W1A || smart
|-
| W1H || Freightliner Econic
|-
| W1K || Mercedes-Benz car
|-
| W1N || Mercedes-Benz SUV
|-
| W1T || Mercedes-Benz truck
|-
| W1V || Mercedes-Benz van
|-
| W1W || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| W1X || Mercedes-Benz incomplete vehicle (North America)
|-
| W1Y || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| W1Z || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| W2W || Freightliner Sprinter MPV (van with 2 or 3 rows of seats)
|-
| W2X || Freightliner Sprinter incomplete vehicle
|-
| W2Y || Freightliner Sprinter truck (cargo van with 1 row of seats)
|-
| W2Z || Freightliner Sprinter &quot;bus&quot; (van with more than 3 rows of seats)
|-
| XDN || Mercedes Sprinter Classic made by GAZ (Russia)
|-
| XD2 || CTTM Cargoline (truck trailer) (Russia)
|-
| XEA || AmberAvto (Avtotor) (Russia)
|-
| XE2 || AMKAR Automaster (truck trailer) (Russia)
|-
| XF9/B24 || NK Trailers (truck trailer) (Greece)
|-
| XF9/D44 || Militsis (trailer) (Greece)
|-
| XF9/J03 || Christos Nezis (truck trailer) (Greece)
|-
| XF9/J63 || Kaoussis (truck trailer) (Greece)
|-
| XG3 || Petros Petropoulos Group - Ecoshift NOOS electric motorscooters (Greece)
|-
| XG4|| Mpitis (trailer) (Greece)
|-
| XG5 || Stavropoulos trailers (Greece)
|-
| XG6 || MGK Hellenic Motor motorcycles (Greece)
|-
| XG8 || Gorgolis SA motorcycles (Greece)
|-
| XG9/B01 || Sfakianakis bus Greece
|-
| XG9/H33 || Rappas Trailer (Greece)
|-
| XG9/H51 || Eurotrailer Tourlakopoulos (trailer) (Greece)
|-
| XG9/H92 || Diamantis N. &amp; Co. (trailer) (Greece)
|-
| XΗ9/B21 || Hellenic Vehicle Industry - ELVO bus Greece
|-
| XH9/H08 || Poseidonas Litsakis (trailer) (Greece)
|-
| XH9/H34 || Flexi-Wheels (trailer) (Greece)
|-
| XJY || Bonum (truck trailer) (Russia)
|-
| XJ4 || PKTS (PK Transportnye Sistemy) bus (Russia)
|-
| XKM || Volgabus (Russia)
|-
| XLA || DAF Bus International
|-
| XLB || Volvo Car B.V./NedCar B.V. (Volvo Cars)
|-
| XLC || [[../Ford/VIN Codes|Ford]] Netherlands
|-
| XLD || Pacton Trailers B.V.
|-
| XLE || Scania Netherlands
|-
| XLH || Hapert (trailer)
|-
| XLJ || Anssems (trailer)
|-
| XLK || Burg Trailer Service BV (truck trailer)
|-
| XLR || DAF Trucks &amp; Leyland DAF
|-
| XLU || Henra (trailer)
|-
| XLV || DAF Bus
|-
| XLW || Terberg Benschop BV
|-
| XL3 || Ebusco
|-
| XL4 ||Lightyear
|-
| XL9/001 || ESVE BV (truck trailers)
|-
| XL9/002 || Jumbo Groenewegen (truck trailers)
|-
| XL9/003 || Autobusfabriek Bova BV
|-
| XL9/004 || G.S. Meppel (truck trailers)
|-
| XL9/007|| Broshuis BV (truck trailer)
|-
| XL9/010|| Ginaf Trucks
|-
| XL9/014 || Contar (truck trailer)
|-
| XL9/017 || Van Eck (truck trailer)
|-
| XL9/021 || Donkervoort Cars
|-
| XL9/033 || Wijer (trailer)
|-
| XL9/039 || Talson (truck trailer)
|-
| XL9/042 || Den Oudsten Bussen
|-
| XL9/052 || Witteveen (trailer)
|-
| XL9/055 || Fripaan (truck trailer)
|-
| XL9/067 || HTF (truck trailer)
|-
| XL9/068 || Vogelzang (truck trailer)
|-
| XL9/069 || Kraker (truck trailer)
|-
| XL9/070 || Veldhuizen (truck trailers)
|-
| XL9/073 || Zwalve (truck trailers)
|-
| XL9/074 || Draco (truck trailers)
|-
| XL9/081 || EBO van Weel (truck trailers)
|-
| XL9/084 || Vocol (truck trailers)
|-
| XL9/089 || Meijvo (trailers)
|-
| XL9/092 || Bulthuis (truck trailers)
|-
| XL9/103 || D-TEC (truck trailers)
|-
| XL9/109|| Groenewold Carrosseriefabriek B.V. (car transporter)
|-
| XL9/150 || Univan (truck trailer)
|-
| XL9/251 || Spierings Mobile Cranes
|-
| XL9/320 || VDL Bova bus
|-
| XL9/348 || HOKA (trailer)
|-
| XL9/355 || Berdex (truck trailer)
|-
| XL9/363 || Spyker
|-
| XL9/423 || Tijhof (trailer)
|-
| XL9/461 || BK Market Trailers (trailer)
|-
| XL9/495 || BE-Combi (truck trailer)
|-
| XL9/508 || Talson (truck trailer)
|-
| XL9/527 || GINAF
|-
| XL9/530 || Ebusco
|-
| XL9/611 || Zocon (trailer)
|-
| XMC || NedCar B.V. Mitsubishi Motors (LHD)
|-
| XMD || NedCar B.V. Mitsubishi Motors (RHD)
|-
| XMG || VDL Bus International
|-
| XMR || Nooteboom Trailers 
|-
| XM4 || RAVO Holding B.V. (sweeper)
|-
| XNB || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - RHD)
|-
| XNC || NedCar B.V. Mitsubishi Motors made by Pininfarina (Colt CZC convertible - LHD)
|-
| XNJ || Broshuis (truck trailer)
|-
| XNL || VDL Bus &amp; Coach
|-
| XNT || Pacton Trailers B.V. (truck trailer)
|-
| XN1 || Kraker Trailers Axel B.V. (truck trailer)
|-
| XPN || Knapen Trailers
|-
| XPP || Atec Trailers
|-
| XP7 || Tesla Europe (based in the Netherlands) (Gigafactory Berlin-Brandenburg)
|-
| XRP || Proline (trailer)
|-
| XRY || D-TEC (truck trailer)
|-
| XR7 || Qarry
|-
| XTA || Lada / AvtoVAZ (Russia)
|-
| XTB || Moskvitch / AZLK (Russia)
|-
| XTC || KAMAZ (Russia)
|-
| XTD || LuAZ (Ukraine)
|-
| XTE || ZAZ (Ukraine)
|-
| XTF || GolAZ (Russia) 
|-
| XTH || GAZ (Russia)
|-
| XTJ || Lada Oka made by SeAZ (Russia)
|-
| XTK || IzhAvto (Russia)
|-
| XTM || MAZ (Belarus); used until 1997
|-
| XTP || Ural (Russia)
|-
| XTS || ChMZAP (truck trailer)
|-
| XTT || UAZ / Sollers (Russia)
|-
| XTU || Trolza, previously ZiU (Russia)
|-
| XTW || LAZ (Ukraine)
|-
| XTY || LiAZ (Russia)
|-
| XTZ || ZiL (Russia)
|-
| XUF || General Motors Russia
|-
| XUS || Nizhegorodets (minibus) (Russia)
|-
| XUU || Avtotor (Russia, Chevrolet SKD, Kaiyi Auto)
|-
| XUV || Avtotor (DFSK, SWM)
|-
| XUZ || InterPipeVAN (truck trailer)
|-
| XU6 || Avtodom (minibus) (Russia)
|-
| XVG || MARZ (bus) (Russia)
|-
| XVU || Start (truck trailer)
|-
| XW7 || Toyota Motor Manufacturing Russia
|-
| XW8 || Volkswagen Group Russia (VW, Skoda)
|-
| XWB || UZ-Daewoo/GM Uzbekistan/Ravon/UzAuto Motors (Uzbekistan)
|-
| XWB || Avtotor (Russia, BAIC SKD)
|-
| XWE || Avtotor (Russia, Hyundai-Kia SKD)
|-
| XWF || Avtotor (Russia, Chevrolet Tahoe/Opel/Cadillac/Hummer SKD)
|-
| XX3 || Ujet Manufacturing (Luxembourg)
|-
| XZB || SIMAZ (bus) (Russia)
|-
| XZE || Specpricep (truck trailer)
|-
| XZG || Great Wall Motor (Haval Motor Rus)
|-
| XZP || Gut Trailer (truck trailer)
|-
| XZT || FoxBus (minibus) (Russia)
|-
| X1D || RAF (Rīgas Autobusu Fabrika) (Latvia)
|-
| X1E || KAvZ (Russia)
|-
| X1F || NefAZ (Russia)
|-
| X1M || PAZ (Russia)
|-
| X1P || Ural (Russia)
|-
| X2L || Fox Trailer (truck trailer) (Russia)
|-
| X21 || Diesel-S (truck trailer) (Russia)
|-
| X4K || Volgabus (Volzhanin) (Russia)
|-
| X4T || Sommer (truck trailer) (Russia)
|-
| X4X || Avtotor (Russia, BMW SKD)
|-
| X5A || UralSpetzTrans (trailer) (Russia)
|-
| X6D || VIS-AVTO (Russia)
|-
| X6S || TZA (truck trailer) (Russia)
|-
| X7L || Renault AvtoFramos (1998-2014), Renault Russia (2014-2022), Moskvitch (2022-) (Russia)
|-
| X7M || [[../Hyundai/VIN Codes|Hyundai]] &amp; Vortex (rebadged Chery) made by TagAZ (Russia)
|-
| X89/AD4 || ВМЗ (VMZ) bus
|-
| X89/BF8 || Rosvan bus
|-
| X89/CU2 || EvoBus Russland (bus)
|-
| X89/DJ2 || VMK (bus)
|-
| X89/EY4 || Brabill (minibus)
|-
| X89/FF6 || Lotos (bus)
|-
| X89/FY1 || Sherp 
|-
| X8J || IMZ-Ural Ural Motorcycles
|-
| X8U || Scania Russia
|-
| X9F || Ford Motor Company ZAO
|-
| X9L || GM-AvtoVAZ
|-
| X9N || Samoltor (minibus)
|-
| X9P || Volvo Vostok ZAO (Volvo Trucks)
|-
| X9W || Brilliance, Lifan made by Derways
|-
| X9X || Great Wall Motors 
|-
| X96 || GAZ
|-
| X99/000 || Marussia
|-
| X90 || GRAZ (truck trailer)
|-
| X0T || Tonar (truck trailer)
|-
| YAF || Faymonville (special transport trailers)
|-
| YAG || Syma aanhangwagenbouw BV (trailers)
|-
| YAM || MAX Trailer (truck trailers)
|-
| YAR || Toyota Motor Europe (based in Belgium) used for Toyota ProAce, Toyota ProAce City and Toyota ProAce Max made by PSA/Stellantis
|-
| YA2 || Atlas Copco Group
|-
| YA5 || Renders (truck trailers)
|-
| YA9/ || Lambrecht Constructie NV (truck trailers)
|-
| YA9/111 || OVA (truck trailer)
|-
| YA9/121 || Atcomex (truck trailer)
|-
| YA9/128 || EOS (bus)
|-
| YA9/139 || ATM Maaseik (truck trailer)
|-
| YA9/168 || Forthomme s.a. (truck trailer)
|-
| YA9/169 || Automobiles Gillet
|-
| YA9/180 || EOS (bus)
|-
| YA9/191 || Stokota (truck trailers)
|-
| YA9/195 || Denolf &amp; Depla (minibus)
|-
| YBC || Toyota Supra (Fifth generation for Europe)
|-
| YBD || Addax Motors
|-
| YBW || Volkswagen Belgium
|-
| YB1 || Volvo Trucks Belgium (truck)
|-
| YB2 || Volvo Trucks Belgium (bus chassis)
|-
| YB3 || Volvo Trucks Belgium (incomplete vehicle)
|-
| YB4 || LAG Trailers N.V. (truck trailer)
|-
| YB6 || Jonckheere (VDL Belgium)
|-
| YCM || Mazda Motor Logistics Europe (based in Belgium) used for European-market Mazda 121 made by Ford in UK
|-
| YC1 || Honda Belgium NV (motorcycle)
|-
| YC3 || Eduard Trailers
|-
| YD3 || Chateau Caravans (Belgium)
|-
| YE1 || Van Hool (trailers) (Belgium)
|-
| YE2 || Van Hool (buses) (Belgium)
|-
| YE6 || STAS (truck trailer)
|-
| YE7 || Turbo's Hoet (truck trailer)
|-
| YF1 || Närko (truck trailer) (Finland)
|-
| YF3 || NTM (truck trailer) (Finland)
|-
| YF9/050 || JYKI (truck trailer) (Finland)
|-
| YGU || JJ-Trailer (trailer) (Finland)
|-
|YG6
|Majava Group Oy; Majava trailers (Finland)
|-
| YH1 || Solifer (caravans)
|-
| YH2 || BRP Finland (Lynx snowmobiles)
|-
| YH4 || Fisker Automotive (Fisker Karma) built by Valmet Automotive
|-
| YK1 || Saab-Valmet Finland
|-
| YK2, YK7 || Sisu Auto
|-
| YK9/003 || Kabus (bus)
|-
| YK9/008 || Lahden Autokori (-2013), SOE Busproduction Finland (2014-2024) (bus)
|-
| YK9/016 || Linkker (bus)
|-
| YSC || Cadillac BLS (made by Saab)
|-
| YSM || Polestar cars 
|-
| YSP || Volta Trucks AB
|-
| YSR || Polestar SUV
|-
| YS2 || Scania commercial vehicles (Södertälje factory) 
|-
| YS3 || Saab cars
|-
| YS4 || Scania buses and bus chassis until 2002 (Katrineholm factory)
|-
| YS5 || OmniNova (minibus)
|-
| YS7 || Solifer (recreational vehicles)
|-
| YS9/KV1 || Backaryd (minibus)
|-
| YTN || Saab made by NEVS
|-
| YT7 || Kabe (recreational vehicles)
|-
| YT9/007 || Koenigsegg
|-
| YT9/034 || Carvia
|-
| YU1 || Fogelsta, Brenderup Group (trailer)
|-
| YU7 || Husaberg (motorcycles)
|-
| YVV || WiMa 442 EV
|-
| YV1 || [[../Volvo/VIN Codes|Volvo]] cars
|-
| YV2 || [[../Volvo/VIN Codes|Volvo]] trucks
|-
| YV3 || [[../Volvo/VIN Codes|Volvo]] buses and bus chassis
|-
| YV4 || [[../Volvo/VIN Codes|Volvo]] SUV
|-
| YV5 || [[../Volvo/VIN Codes|Volvo Trucks]] incomplete vehicle
|-
| YYB || Tysse (trailer) (Norway)
|-
| YYC || Think Nordic (Norway)
|-
| YY9/017 || Skala Fabrikk (truck trailer) (Norway)
|-
| Y29/005 || Buddy Electric (Norway)
|-
| Y3D || MTM (truck trailer) (Belarus)
|-
| Y3F || Lida Buses Neman (Belarus)
|-
| Y3J || Belkommunmash (Belarus)
|-
| Y3K || Neman Bus (Belarus)
|-
| Y3M || MAZ (Belarus)
|-
| Y3W || VFV built by Unison (Belarus)
|-
| Y39/047 || Altant-M (minibus) (Belarus)
|-
| Y39/051 || Bus-Master (minibus) (Belarus)
|-
| Y39/052 || Aktriya (minibus) (Belarus)
|-
| Y39/072 || Klassikbus (minibus) (Belarus)
|-
| Y39/074 || Alterra (minibus) (Belarus)
|-
| Y39/135 || EuroDjet (minibus) (Belarus)
|-
| Y39/240 || Alizana (minibus) (Belarus)
|-
| Y39/241 || RSBUS (minibus) (Belarus)
|-
| Y39/323 || KF-AVTO (minibus) (Belarus)
|-
| Y4F || [[../Ford/VIN Codes|Ford]] Belarus
|-
| Y4K || Geely / BelGee (Belarus)
|-
| Y6B || Iveco (Ukraine)
|-
| Y6D || ZAZ / AvtoZAZ, Chevrolet Lanos made by ZAZ (Ukraine)
|-
| Y6E || LAZ (Ukraine)
|-
| Y6J || Bogdan group (Ukraine)
|-
| Y6L || Bogdan group including buses, Lada, &amp; Hyundai made by Bogdan (Ukraine)
|-
| Y6U || Škoda Auto made by Eurocar (Ukraine)
|-
| Y6W || PGFM (trailer) (Ukraine)
|-
| Y6Y || LEV (trailer) (Ukraine)
|-
| Y69/B19 || Stryi Avto (bus) (Ukraine)
|-
| Y69/B98 || VESTT (truck trailer) (Ukraine)
|-
| Y69/C49 || TAD (truck trailer) (Ukraine)
|-
| Y69/D75 || Barrel Dash (truck trailer) (Ukraine)
|-
| Y7A || KrAZ trucks (Ukraine)
|-
| Y7B || Bogdan group (Ukraine)
|-
| Y7C || Great Wall Motors, Geely made by KrASZ (Ukraine)
|-
| Y7D || GAZ made by KrymAvtoGAZ (Ukraine)
|-
| Y7F || Boryspil Bus Factory (BAZ) (Ukraine)
|-
| Y7S || Korida-Tech (trailer) (Ukraine)
|-
| Y7W || Geely made by KrASZ (Ukraine)
|-
| Y7X || ChRZ - Ruta (minibus) (Ukraine)
|-
| Y79/A23 || OdAZ (truck trailer) (Ukraine)
|-
| Y79/B21 || Everlast (truck trailer) (Ukraine)
|-
| Y79/B65 || Avtoban (trailer) (Ukraine)
|-
| Y8A || LAZ (Ukraine)
|-
| Y8H || UNV Leader (trailer) (Ukraine)
|-
| Y8S || Alekseevka Ximmash (truck trailer) 
|-
| Y8X || GAZ Gazelle made by KrASZ (Ukraine)
|-
| Y89/A98 || VARZ (trailer) (Ukraine)
|-
| Y89/B75 || Knott (trailer) (Ukraine)
|-
| Y89/C65 || Electron (Ukraine)
|-
| Y9A || PAVAM (trailer) (Ukraine)
|-
| Y9H || LAZ (Ukraine)
|-
| Y9M || AMS (trailer) (Ukraine)
|-
| Y9T || Dnipro (trailer) (Ukraine)
|-
| Y9W || Pragmatec (trailer) (Ukraine)
|-
| Y9Z || Lada, Renault made in Ukraine
|-
| Y99/B32 || Santey (trailer) (Ukraine)
|-
| Y99/E21 || Zmiev-Trans (truck trailer) (Ukraine)
|-
| Y99/C79 || Electron (bus) (Ukraine)
|-
| ZAA || Autobianchi
|-
| ZAA || Alfa Romeo Junior 2024-
|-
| ZAC || Jeep, Dodge Hornet
|-
| ZAH || Rolfo SpA (car transporter)
|-
| ZAJ || Trigano SpA; Roller Team recreational vehicles
|-
| ZAM || [[../Maserati/VIN Codes|Maserati]]
|-
| ZAP || Piaggio/Vespa/Gilera
|-
| ZAR || Alfa Romeo car
|-
| ZAS || Alfa Romeo Alfasud &amp; Sprint through 1989
|-
| ZAS || Alfa Romeo SUV 2018-
|-
| ZAX || Zorzi (truck trailer)
|-
| ZA4 || Omar (truck trailer)
|-
| ZA9/A12 || [[../Lamborghini/VIN Codes|Lamborghini]] through mid-2003 (including LM002)
|-
| ZA9/A17 || Carrozzeria Luigi Dalla Via (bus)
|-
| ZA9/A18 || De Simon (bus)
|-
| ZA9/A33 || Bucher Schörling Italia (sweeper)
|-
| ZA9/A47 || Silver Car (truck trailer)
|-
| ZA9/B09 || Mauri Bus System
|-
| ZA9/B34 || Mistrall Siloveicoli (truck trailer)
|-
| ZA9/B45 || Bolgan (truck trailer)
|-
| ZA9/B49 || OMSP Macola (truck trailer)
|-
| ZA9/B95 || Carrozzeria Autodromo Modena (bus)
|-
| ZA9/C38 || Dulevo (sweeper)
|-
| ZA9/D38 || Cizeta Automobili SRL
|-
| ZA9/D39 || [[../Bugatti/VIN Codes|Bugatti Automobili S.p.A]]
|-
| ZA9/D50 || Italdesign Giugiaro
|-
| ZA9/E15 || Tecnobus Industries S.r.l.
|-
| ZA9/E73 || Sitcar (bus)
|-
| ZA9/E88 || Cacciamali (bus)
|-
| ZA9/F16 || OMT (truck trailer)
|-
| ZA9/F21 || FGM (truck trailer)
|-
| ZA9/F48 || Rampini Carlo S.p.A. (bus)
|-
| ZA9/F76 || Pagani Automobili S.p.A.
|-
| ZA9/G97 || EPT Horus (bus)
|-
| ZA9/H02 || O.ME.P.S. (truck trailer)
|-
| ZA9/H44|| Green-technik by Green Produzione s.r.l. (machine trailer)
|-
| ZA9/J21 || VRV (truck trailer)
|-
| ZA9/J93 || Barbi (bus)
|-
| ZA9/K98 || Esagono Energia S.r.l.
|-
| ZA9/M09 || Italdesign Automobili Speciali
|-
| ZA9/M27 || Dallara Stradale
|-
| ZA9/M91 || Automobili Pininfarina
|-
| ZA9/180 || De Simon (bus)
|-
| ZA0 || Acerbi (truck trailer)
|-
| ZBA || Piacenza (truck trailer)
|-
| ZBB || Bertone
|-
| ZBD || InBus
|-
| ZBN || Benelli
|-
| ZBW || Rayton-Fissore Magnum
|-
| ZB3 || Cardi (truck trailer)
|-
| ZCB || E. Bartoletti SpA (truck trailer)
|-
| ZCF || Iveco / Irisbus (Italy)
|-
| ZCG || Cagiva SpA / MV Agusta
|-
| ZCG || Husqvarna Motorcycles Under MV Agusta ownership
|-
| ZCM || BredaMenarinibus / Menarinibus / IIA (Industria Italiana Autobus)
|-
| ZCN || Astra Veicoli Industriali S.p.A.
|-
| ZCV || Vibreti (truck trailer)
|-
| ZCZ || BredaBus
|-
| ZC1 || AnsaldoBreda S.p.A.
|-
| ZC2 || Chrysler TC by Maserati
|-
| ZDC || Honda Italia Industriale SpA
|-
| ZDF || [[../Ferrari/VIN Codes|Ferrari]] Dino
|-
| ZDJ || ACM Biagini
|-
| ZDM || Ducati Motor Holdings SpA
|-
| ZDT || De Tomaso Modena SpA
|-
| ZDY || Cacciamali
|-
| ZD0 || Yamaha Motor Italia SpA &amp; Belgarda SpA
|-
| ZD3 || Beta Motor
|-
| ZD4 || Aprilia
|-
| ZD5 || Casalini
|-
| ZEB || Ellebi (trailer)
|-
| ZEH || Trigano SpA (former SEA Group); McLouis &amp; Mobilvetta recreational vehicles
|-
| ZES || Bimota
|-
| ZEX || TM Racing (motorcycle)
|-
| ZE5 || Carmosino (truck trailer)
|-
| ZFA || Fiat
|-
| ZFB || Fiat MPV/SUV &amp; Ram Promaster City
|-
| ZFC || Fiat truck (Fiat Ducato for Mexico, Ram 1200)
|-
| ZFE || KL Motorcycle
|-
| ZFF || [[../Ferrari/VIN Codes|Ferrari]]
|-
| ZFJ || Carrozzeria Pezzaioli (truck trailer)
|-
| ZFM || Fantic Motor
|-
| ZFR || Pininfarina
|-
| ZF4 || Qvale
|-
| ZGA || Iveco Bus
|-
| ZGP || Merker (truck trailer)
|-
| ZGU || Moto Guzzi
|-
| ZG2 || FAAM (commercial vehicle)
|-
| ZHU || Husqvarna Motorcycles Under Cagiva ownership
|-
| ZHW || [[../Lamborghini/VIN Codes|Lamborghini]] (Mid-2003 – )
|-
| ZHZ || Menci SpA (truck trailer)
|-
| ZH5 || FB Mondial (motorcycle)
|-
| ZJM || Malaguti
|-
| ZJN || Innocenti
|-
| ZJT || Italjet
|-
| ZKC || Ducati Energia Free Duck (electric quadricycle)
|-
| ZKH || Husqvarna Motorcycles Srl Under BMW ownership
|-
| ZLA || Lancia
|-
| ZLF || Tazzari GL SpA
|-
| ZLM || Moto Morini srl
|-
| ZLV || Laverda
|-
| ZNN || Energica
|-
| ZN0 || SWM Motorcycles S.r.l.
|-
| ZN3 || Iveco Defence
|-
| ZN6 || Maserati SUV
|-
| ZPB || [[../Lamborghini/VIN Codes|Lamborghini]] SUV
|-
| ZPY || DR Automobiles
|-
| ZP6 || XEV
|-
| ZP8 || Regis Motors
|-
| ZRG || Tazzari GL Imola SpA
|-
| ZR1 || Microlino
|-
| ZSG || [[../Ferrari/VIN Codes|Ferrari]] SUV
|-
| ZX1 || TAM (Tovarna Avtomobilov Maribor) bus (Slovenia)
|-
| ZX9/KU0 || K-Bus / Kutsenits (bus) (Slovenia)
|-
| ZX9/DUR || TAM bus (Slovenia)
|-
| ZX9/TV0 || TAM (Tovarna Vozil Maribor) bus (Slovenia)
|-
| ZY1 || Adria (recreational vehicles) (Slovenia)
|-
| ZY9/002 || Gorica (truck trailer) (Slovenia)
|-
| ZZ1 || Tomos motorcycle (Slovenia)
|-
| Z29/555 || Vozila FLuid (truck trailer) (Slovenia)
|-
| Z3D || Tauriga UAB; Tauras trailers (Lithuania)
|-
| Z39/008 || Autogalantas (truck trailer) (Lithuania)
|-
| Z39/009 || Patikima Linija / Rimo (truck trailer) (Lithuania)
|-
| Z6F || Ford Sollers (Russia)
|-
| Z7C || Luidor (bus) (Russia)
|-
| Z7N || KAvZ (bus) (Russia)
|-
| Z7T || RoAZ (bus) (Russia)
|-
| Z7X || Isuzu Rus (Russia)
|-
| Z76 || SEMAZ (Kazakhstan)
|-
| Z8M || Marussia (Russia)
|-
| Z8N || Nissan Manufacturing Rus (Russia)
|-
| Z8T || PCMA Rus (Peugeot, Citroen, Mitsubishi) (Russia)
|-
| Z8U || [[w:SsangYong Korando#Third generation (C200; 2010)|Ssangyong Actyon]] made by Sollers (Russia)
|-
| Z8Y || Nasteviya (bus) (Russia)
|-
| Z9B || KuzbassAvto (Hyundai bus) (Russia)
|-
| Z9M || Mercedes-Benz Manufacturing Rus / Mercedes-Benz Trucks Vostok (Russia)
|-
| Z9N || Samotlor-NN (Iveco) (Russia)
|-
| Z94 || Hyundai Motor Manufacturing Rus (Hyundai, Kia) (2008-2023), Solaris Auto - AGR Automotive (2023-) (Russia)
|-
| Z07 || Volgabus (Russia)
|-
| 1A4 1A8 || Chrysler brand MPV/SUV 2006–2009 only
|-
| 1A9/007 || Advance Mixer Inc.
|-
| 1A9/111 || Amerisport Inc. (federalized late model DeTomaso Pantera)
|-
| 1A9/398 || Ameritech (federalized McLaren F1 &amp; Bugatti EB110)
|-
| 1A9/569 || American Custom Golf Cars Inc. (AGC)
|-
| 1AC || American Motors Corporation MPV
|-
| 1AF || American LaFrance truck
|-
| 1AJ || Ajax Manufacturing (truck trailer)
|-
| 1AM || American Motors Corporation car &amp; Renault Alliance 1983 only
|-
| 1BN || Beall Trailers (truck trailer)
|-
| 1B3 || Dodge car 1981–2011
|-
| 1B4 || Dodge MPV/SUV 1981–2002
|-
| 1B6 || Dodge incomplete vehicle 1981–2002
|-
| 1B7 || Dodge truck 1981–2002
|-
| 1B9/133 || Buell Motorcycle Company through mid-1995
|-
| 1B9/274 || Brooks Brothers Trailers
|-
| 1B9/275 || Boydstun Metal Works (truck trailer)
|-
| 1B9/285 || Boss Hoss Cycles
|-
| 1B9/374 || Big Dog Custom Motorcycles through mid-2002
|-
| 1B9/975 || Motus Motorcycles
|-
| 1BA || Blue Bird Corporation bus
|-
| 1BB || Blue Bird Wanderlodge MPV
|-
| 1BD || Blue Bird Corporation incomplete vehicle
|-
| 1BL || Balko, Inc.
|-
| 1C3 || Chrysler brand car 1981–2011
|-
| 1C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 1C4 || Chrysler brand MPV 1990–2005
|-
| 1C4 || Chrysler Group (all brands) MPV 2012–
|-
| 1C6 || Chrysler Group (all brands) truck 2012–
|-
| 1C8 || Chrysler brand MPV 2001–2005
|-
| 1C9/257 || CEI Equipment Company (truck trailer)
|-
| 1C9/291 || CX Automotive
|-
| 1C9/496 || Carlinville Truck Equipment (truck trailer)
|-
| 1C9/535 || Chance Coach (bus)
|-
| 1C9/737 || Corbin Motors, Inc.
|-
| 1C9/772 || Cozad (truck trailer)
|-
| 1C9/971 || Cool Amphibious Manufacturers International
|-
| 1CM || Checker Motors Corporation
|-
| 1CU || Cushman Haulster (Cushman division of Outboard Marine Corporation)
|-
| 1CY || Crane Carrier Company
|-
| 1CY || Battle Motors, Inc.
|-
| 1D3 || Dodge truck 2002–2009
|-
| 1D4 || Dodge MPV/SUV 2003–2011 only
|-
| 1D7 || Dodge truck 2002–2011
|-
| 1D8 || Dodge MPV/SUV 2003–2009 only
|-
| 1D9/008 || KME Fire Apparatus
|-
| 1D9/628 || Dymac Vehicle Group (low-speed vehicle)
|-
| 1D9/791 || Dennis Eagle, Inc.
|-
| 1DW || Stoughton Trailers (truck trailer)
|-
| 1E9/007 || E.D. Etnyre &amp; Co. (truck trailer)
|-
| 1E9/190 || Electric Transit Inc. (trolleybus)
|-
| 1E9/363 || E-SUV LLC (E-Ride Industries)
|-
| 1E9/456 || Electric Motorsport (GPR-S electric motorcycle)
|-
| 1E9/526 || Epic TORQ
|-
| 1E9/581 || Vetter Razor
|-
| 1EU || Eagle Coach Corporation (bus)
|-
| 1FA || [[../Ford/VIN Codes|Ford]] car
|-
| 1FB || [[../Ford/VIN Codes|Ford]] &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1FC || [[../Ford/VIN Codes|Ford]] stripped chassis made by Ford
|-
| 1FD || [[../Ford/VIN Codes|Ford]] incomplete vehicle
|-
| 1FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 1FT || [[../Ford/VIN Codes|Ford]] truck
|- 
| 1FU || Freightliner (truck)
|-
| 1FV || Freightliner (incomplete vehicle)
|-
| 1F1 || Ford SUV - Limousine (through 2009)
|-
| 1F6 || Ford stripped chassis made by Detroit Chassis LLC
|-
| 1F9/037 || Federal Motors Inc. 
|-
| 1F9/140 || Ferrara Fire Apparatus (incomplete vehicle)
|-
| 1F9/458 || Faraday Future prototypes
|- 
| 1F9/FT1 || FWD Corp.
|-
| 1F9/ST1 || Seagrave Fire Apparatus
|-
| 1F9/ST2 || Seagrave Fire Apparatus
|-
| 1G || [[../GM/VIN Codes|General Motors]] USA
|-
| 1G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 1G0 || GMC Rapid Transit Series (RTS) bus 1981–1984
|-
| 1G0 || Opel/Vauxhall car 2007–2017
|-
| 1G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 1G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 1G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 1G4 || [[../GM/VIN Codes|Buick]] car
|-
| 1G5 || GMC MPV/SUV 1981–1986
|-
| 1G5 || Pontiac incomplete vehicle 1989-1990, 2003-2006
|-
| 1G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 1G7 || Pontiac car only sold by GM Canada
|-
| 1G8 || Chevrolet MPV/SUV 1981–1986
|-
| 1G8 || [[../GM/VIN Codes|Saturn]] car 1991–2010
|-
| 1G9/492 || GreenPower Motor Company incomplete vehicle 
|-
| 1G9/495 || Google &amp; Waymo
|-
| 1GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 1GB || Chevrolet incomplete vehicle
|-
| 1GC || [[../GM/VIN Codes|Chevrolet]] truck 
|-
| 1GD || GMC incomplete vehicle
|-
| 1GE || Cadillac incomplete vehicle
|-
| 1GF || Flxible bus
|-
| 1GG || Isuzu pickup trucks made by GM
|-
| 1GH || GMC Rapid Transit Series (RTS) bus 1985–1986
|-
| 1GH || Oldsmobile MPV/SUV 1990–2004
|-
| 1GH || Holden Acadia 2019–2020
|-
| 1GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987–
|-
| 1GK || GMC MPV/SUV 1987–
|-
| 1GM || [[../GM/VIN Codes|Pontiac]] MPV
|-
| 1GN || [[../GM/VIN Codes|Chevrolet]] MPV/SUV 1987-
|-
| 1GR || Great Dane Trailers (truck trailer)
|-
| 1GT || [[../GM/VIN Codes|GMC]] Truck 
|-
| 1GW || Grumman Olson Kubvan (truck)
|-
| 1GY || [[../GM/VIN Codes|Cadillac]] SUV
|-
| 1HA || Chevrolet incomplete vehicles (Express cutaway) made by Navistar International/International Motors
|-
| 1HD || Harley-Davidson &amp; LiveWire
|-
| 1HF || Honda motorcycle/ATV/UTV
|-
| 1HG || [[../Honda/VIN Codes|Honda]] car made by Honda of America Mfg. in Ohio
|-
| 1HP || International Trucks (complete vehicle - straight truck)
|-
| 1HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 1HT || International Trucks &amp; Caterpillar Trucks &amp; Chevrolet Silverado 4500HD, 5500HD, 6500HD (incomplete vehicle - straight truck)
|-
| 1HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 1H9/484 || Hughes Trailers (Based in Canyon, TX) (trailer)
|-
| 1H9/674 || Hines Specialty Vehicle Group
|-
| 1JC || Jeep SUV 1981–1988 (using AMC-style VIN structure)
|-
| 1JJ || Wabash (truck trailer)
|-
| 1JT || Jeep truck 1981–1988 (using AMC-style VIN structure)
|-
| 1JU || Marmon Motor Company (truck)
|-
| 1J4 || Jeep SUV 1989–2011 (using Chrysler-style VIN structure)
|-
| 1J7 || Jeep truck 1989–1992 (using Chrysler-style VIN structure)
|-
| 1J8 || Jeep SUV 2002–2011 (using Chrysler-style VIN structure)
|-
| 1KB || Holiday Rambler Corp. 1981-2010 (trailer)
|-
| 1K9/058 || Kovatech Mobile Equipment (fire engine)
|-
| 1LH || Landoll (truck trailer)
|-
| 1LJ || Lincoln incomplete vehicle
|-
| 1LN || [[../Ford/VIN Codes|Lincoln]] car
|-
| 1LV || Lectra Motors
|-
| 1L0 || Lufkin Trailers
|-
| 1L1 || Lincoln car – limousine
|-
| 1L9/155 || LA Exotics
|-
| 1L9/234 || Laforza
|-
| 1MB || Mercedes-Benz Truck Co.
|-
| 1ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 1MR || Continental Mark VI &amp; VII 1981–1985 &amp; Continental sedan 1982–1985
|-
| 1M0 || John Deere Gator
|-
| 1M1 || Mack Truck USA (truck)
|-
| 1M2 || Mack Truck USA (incomplete vehicle)
|-
| 1M3 || Mack Truck USA (glider)
|-
| 1M8 || Motor Coach Industries (bus)
|-
| 1M9/089 || Mauck Special Vehicles (bus)
|-
| 1M9/682 || Mosler Automotive
|-
| 1M9/816 || Proterra Through mid-2019
|-
| 1N4 || Nissan car
|-
| 1N6 || Nissan truck
|-
| 1N9/019 || Neoplan USA
|-
| 1N9/084 || Eldorado National (California)
|-
| 1N9/140 || North American Bus Industries (bus)
|-
| 1N9/393 || Nikola Corporation (truck)
|-
| 1NK || Kenworth (incomplete vehicle)
|-
| 1NL || Gulf Stream Coach (recreational vehicles)
|-
| 1NN || Monon made by Evans Products Co. (truck trailer)
|-
| 1NP || Peterbilt (incomplete vehicle)
|-
| 1NX || Toyota car made by NUMMI
|-
| 1P3 || Plymouth car
|-
| 1P4 || Plymouth MPV/SUV
|-
| 1P7 || Plymouth Scamp
|-
| 1P9/038 || Hawk Vehicles, Inc. (Trihawk motorcycles)
|-
| 1P9/213 || Panoz
|-
| 1P9/255 || Pinson Truck Equipment Company (truck trailer)
|-
| 1PM || Polar Tank Trailer (truck trailer)
|-
| 1PT || Trailmobile Trailer Corporation (truck trailer)
|-
| 1PY || John Deere USA
|-
| 1RF || Roadmaster, Monaco Coach Corporation (incomplete vehicle)
|-
| 1RN || Reitnouer (truck trailer)
|-
| 1R9/956 || Reede Fabrication and Design (motorcycles)
|-
| 1ST || Airstream (recreational vehicles)
|-
| 1S1 || Strick Trailers (truck trailer)
|-
| 1S9/003 || Sutphen Corporation (fire engines - truck)
|-
| 1S9/009|| Superior Trailer Works (truck trailer)
|-
| 1S9/098 || Scania AB (Scania CN112 bus made in Orange, CT)
|-
| 1S9/842 || Saleen S7
|-
| 1S9/260 || Stairs Welding RL (truck trailer)
|-
| 1S9/901 || Suckerpunch Sallys, LLC
|-
| 1S9/944 || SSC North America
|-
| 1TD || Timpte (truck trailer)
|-
| 1TK || Trail King (truck trailer)
|-
| 1TD || Transcraft Corporation (truck trailer)
|-
| 1T7 || Thomas Built Buses
|-
| 1T8 || Thomas Built Buses
|-
| 1T9/072 || The Trailer Co. (truck trailer)
|-
| 1T9/717 || Thunder Mountain Custom Cycles
|-
| 1T9/825 || TICO Manufacturing Company (truck)
|-
| 1T9/899 || Tomcar USA
|-
| 1T9/970 || Three Two Chopper
|-
| 1TC || Coachmen Recreational Vehicle Co., LLC
|-
| 1TU || Transportation Manufacturing Corporation
|-
| 1UJ || Jayco, Inc.
|-
| 1UT || AM General military trucks, Jeep DJ made by AM General
|-
| 1UY || Utility Trailer (truck trailer)
|-
| 1VH || Orion Bus Industries
|-
| 1VW || Volkswagen car
|-
| 1V1 || Volkswagen truck
|-
| 1V2 || Volkswagen SUV
|-
| 1V9/048 || Vector Aeromotive
|-
| 1V9/113 || Vantage Vehicle International Inc (low-speed vehicle)
|-
| 1V9/190 || Vanderhall Motor Works
|-
| 1WA || White Motor Company (Autocar brand truck)
|-
| 1WB || White Motor Company (Autocar brand incomplete vehicle)
|-
| 1WD || White Motor Company (Autocar brand glider)
|-
| 1WT || Winnebago Industries: Winnebago M.P.V.
|-
| 1WU || White Motor Company (White brand truck)
|-
| 1WV || Winnebago Industries: Winnebago M.P.V. - Class C Motorhome built on VW chassis &amp; front cab [Winnebago Rialta ('95-'96)]
|-
| 1WW || Winnebago Industries: Winnebago M.P.V. - Class B Motorhome built on Renault chassis [Winnebago LeSharo, Centauri, Itasca Phasar]
|-
| 1WX || White Motor Company (White brand incomplete vehicle)
|-
| 1WY || White Motor Company (White brand glider)
|-
| 1W1 || Wilson Trailer Co. (truck trailer)
|-
| 1W5 || Western Recreational Vehicles (Alpenlite)
|-
| 1W8 || Witzco (truck trailer)
|-
| 1W9/010 || Weld-It Company (truck trailer)
|-
| 1W9/485 || Wheego Electric Cars
|-
| 1W9/488 || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (2010 &amp; later)
|-
| 1XA || Excalibur Automobile Corporation
|-
| 1XK || Kenworth (truck)
|-
| 1XM || Renault Alliance/GTA/Encore 1984–1987
|-
| 1XP || Peterbilt (truck)
|-
| 1Y1 || Chevrolet/Geo car made by NUMMI
|-
| 1YJ || Rokon International, Inc.
|-
| 1YV || [[../Ford/VIN Codes|Mazda made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZV || [[../Ford/VIN Codes|Ford made by Mazda Motor Manufacturing USA/AutoAlliance International]]
|-
| 1ZW || [[../Ford/VIN Codes|Mercury made by AutoAlliance International]]
|-
| 1Z3 1Z7 || Mitsubishi Raider
|-
| 1Z9/170 || [[w:Orange County Choppers|Orange County Choppers]]
|-
| 10B || Brenner Tank (truck trailer)
|-
| 10R || E-Z-GO
|-
| 10T || Oshkosh Corporation 
|-
| 11H || Hendrickson Mobile Equipment, Inc. (fire engines - incomplete vehicle)
|-
| 11V || Kalmar Solutions (Truck - Terminal Tractor)
|-
| 12A || Avanti
|-
| 137 || AM General Hummer &amp; Hummer H1
|-
| 13N || Fontaine (truck trailer)
|-
| 15G || Gillig bus
|-
| 16C || Clenet Coachworks
|-
| 16W || Certified Stainless Services Inc. DBA West-Mark (truck trailer) (prior to 2010)
|-
| 16X || Vixen 21 motorhome
|-
| 17N || John Deere incomplete vehicle (RV chassis)
|-
| 18X || Western Recreational Vehicles
|-
| 19U || Acura car made by Honda of America Mfg. in Ohio
|-
| 19V || Acura car made by Honda Manufacturing of Indiana
|-
| 19X || Honda car made by Honda Manufacturing of Indiana
|-
| 2A3 || Imperial
|-
| 2A4 2A8 || Chrysler brand MPV/SUV 2006–2011 only
|-
| 2AY 2AZ || Hino
|-
| 2BC || Jeep Wrangler (YJ) 1987–1988 (using AMC-style VIN structure)
|-
| 2BP || Ski-Doo
|-
| 2BV || Can-Am &amp; Bombardier ATV
|-
| 2BW || Can-Am Commander E LSV
|-
| 2BX || Can-Am Spyder &amp; Canyon 3-wheelers
|-
| 2BZ || Can-Am Freedom Trailer for Can-Am Spyder &amp; Canyon
|-
| 2B1 || Orion Bus Industries
|-
| 2B3 || Dodge car 1981–2011
|-
| 2B4 || Dodge MPV 1981–2002
|-
| 2B5 || Dodge &quot;bus&quot; (van with more than 3 rows of seats) 1981–2002
|-
| 2B6 || Dodge incomplete vehicle 1981–2002
|-
| 2B7 || Dodge truck 1981–2002
|-
| 2B9/001 || BWS Manufacturing (truck trailer)
|-
| 2C1 || Geo/Chevrolet car made by CAMI Automotive
|-
| 2C3 || Chrysler brand car 1981–2011
|-
| 2C3 || Chrysler Group (all brands) car (including Lancia) 2012-
|-
| 2C4 || Chrysler brand MPV/SUV 2000–2005
|-
| 2C4 || Chrysler Group (all brands) MPV (including Lancia Voyager &amp; Volkswagen Routan) 2012-
|-
| 2C7 || Pontiac car made by CAMI Automotive only sold by GM Canada
|-
| 2C8 || Chrysler brand MPV/SUV 2001–2005
|-
| 2C9/145 || Campagna Motors
|-
| 2C9/197 || Canadian Electric Vehicles
|-
| 2CC || American Motors Corporation MPV
|-
| 2CG || Asüna/Pontiac SUV made by CAMI Automotive only sold by GM Canada
|-
| 2CK || GMC Tracker SUV made by CAMI Automotive only sold by GM Canada 1990–1991 only
|-
| 2CK || Pontiac Torrent SUV made by CAMI Automotive 2006–2009 only
|-
| 2CM || American Motors Corporation car
|-
| 2CN || Geo/Chevrolet SUV made by CAMI Automotive 1990–2011 only
|-
| 2CT || GMC Terrain SUV made by CAMI Automotive 2010–2011 only
|-
| 2D4 || Dodge MPV 2003–2011 only
|-
| 2D6 || Dodge incomplete vehicle 2003
|-
| 2D7 || Dodge truck 2003
|-
| 2D8 || Dodge MPV 2003–2011 only
|-
| 2DG || Ontario Drive &amp; Gear
|-
| 2DM || Di-Mond Trailers (truck trailer)
|-
| 2DN || Dynasty Electric Car Corporation
|-
| 2EZ || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2E3 || Eagle car 1989–1997 (using Chrysler-style VIN structure)
|-
| 2E4 || 2011 Lancia MPV (Voyager)
|-
| 2E9/080 || Electra Meccanica Vehicles Corp. (Solo)
|-
| 2FA || [[../Ford/VIN Codes|Ford]] car
|-
| 2FH || Zenn Motor Co., Ltd. (low-speed vehicle)
|-
| 2FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 2FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 2FU || Freightliner (truck)
|-
| 2FV || Freightliner (incomplete vehicle)
|-
| 2FW || Sterling Trucks (truck-complete vehicle)
|-
| 2FY || New Flyer
|-
| 2FZ || Sterling Trucks (incomplete vehicle)
|- 
| 2Gx || [[../GM/VIN Codes|General Motors]] Canada
|-
| 2G0 || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1981–1986
|-
| 2G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 2G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 2G3 || [[../GM/VIN Codes|Oldsmobile]] car
|-
| 2G4 || [[../GM/VIN Codes|Buick]] car
|-
| 2G5 ||  GMC MPV 1981–1986
|-
| 2G5 ||  Chevrolet BrightDrop / BrightDrop Zevo truck 2023-2026
|-
| 2G6 || [[../GM/VIN Codes|Cadillac]] car
|-
| 2G7 ||  Pontiac car only sold by GM Canada
|-
| 2G8 ||  Chevrolet MPV 1981–1986
|-
| 2GA || Chevrolet &quot;bus&quot; (van with more than 3 rows of seats) 
|-
| 2GB || Chevrolet incomplete vehicle
|-
| 2GC || Chevrolet truck 
|-
| 2GD || GMC incomplete vehicle
|-
| 2GE || Cadillac incomplete vehicle 
|-
| 2GH || GMC GM New Look bus &amp; GM Classic series bus 
|-
| 2GJ || GMC &quot;bus&quot; (van with more than 3 rows of seats) 1987– 
|-
| 2GK || GMC MPV/SUV 1987– 
|-
| 2GN || Chevrolet MPV/SUV 1987- 
|-
| 2GT || GMC truck 
|-
| 2HG || [[../Honda/VIN Codes|Honda]] car made by Honda of Canada Manufacturing
|-
| 2HH || Acura car made by Honda of Canada Manufacturing
|-
| 2HJ || [[../Honda/VIN Codes|Honda]] truck made by Honda of Canada Manufacturing
|-
| 2HK || [[../Honda/VIN Codes|Honda]] MPV/SUV made by Honda of Canada Manufacturing
|-
| 2HM || Hyundai Canada
|-
| 2HN || Acura SUV made by Honda of Canada Manufacturing
|-
| 2HP || International Trucks (complete vehicle - straight truck)
|-
| 2HS || International Trucks (complete vehicle - truck tractor)
|-
| 2HT || International Trucks (incomplete vehicle - straight truck)
|-
| 2HV || International or IC Bus (incomplete vehicle - bus) 
|-
| 2J4 || Jeep Wrangler (YJ) 1989–1992 (using Chrysler-style VIN structure)
|-
| 2L1 || Lincoln incomplete vehicle – limo
|-
| 2LD || Triple E Canada Ltd.
|-
| 2LJ || Lincoln incomplete vehicle – hearse
|-
| 2LM || Lincoln SUV
|-
| 2LN || Lincoln car
|-
| 2M1 || Mack Trucks Canada (truck)
|-
| 2M2 || Mack Trucks Canada (incomplete vehicle)
|-
| 2M3 || Mack Truck Canada (glider)
|-
| 2ME || [[../Ford/VIN Codes|Mercury]] car
|-
| 2MG || Motor Coach Industries (Produced from Sept. 1, 2008 on)
|-
| 2MH || [[../Ford/VIN Codes|Mercury]] incomplete vehicle
|-
| 2MR || [[../Ford/VIN Codes|Mercury]] MPV
|-
| 2M9/044 || Westward Industries
|-
| 2M9/058 || Motor Coach Industries
|-
| 2NK || Kenworth incomplete vehicle
|-
| 2NP || Peterbilt incomplete vehicle
|-
| 2NV || Nova Bus 
|-
| 2P3 || Plymouth car
|-
| 2P4 || Plymouth MPV 1981–2000
|-
| 2P5 || Plymouth &quot;bus&quot; (van with more than 3 rows of seats) 1981–1983
|-
| 2P9/001 || Prevost 1981–1995
|-
| 2PC || Prevost 1996-
|-
| 2S2 || Suzuki car made by CAMI Automotive
|-
| 2S3 || Suzuki SUV made by CAMI Automotive
|-
| 2TU || Tri-Star Industries Limited
|-
| 2T1 || [[../Toyota/VIN Codes|Toyota]] car made by TMMC
|-
| 2T2 || Lexus SUV made by TMMC
|-
| 2T3 || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMC
|-
| 2T9/206 || Triple E Canada Ltd.
|-
| 2V4 || Volkswagen Routan made by Chrysler Canada
|-
| 2V8 || Volkswagen Routan made by Chrysler Canada
|-
| 2W9/044 || Westward Industries
|-
| 2WK || Western Star (truck)
|-
| 2WL || Western Star (incomplete vehicle)
|-
| 2WM || Western Star (glider)
|-
| 2XK || Kenworth (truck)
|-
| 2XM || Eagle Premier 1988 only (using AMC-style VIN structure)
|-
| 2XP || Peterbilt (truck)
|-
| 3A4 3A8 || Chrysler brand MPV 2006–2010 only
|-
| 3A9/050 || MARGO (truck trailer)
|-
| 3AK || Freightliner Trucks (truck)
|-
| 3AL || Freightliner Trucks (incomplete vehicle)
|-
| 3AW || Fruehauf de Mexico (truck trailer)
|-
| 3AX || Scania Mexico
|-
| 3BE || Scania Mexico (buses)
|-
| 3BH || Western Star 3700 (truck) made by DINA S.A.
|-
| 3BH || Western Star (truck)
|-
| 3BJ || Western Star 3700 (incomplete vehicle) made by DINA S.A.
|-
| 3BJ || Western Star (incomplete vehicle)
|-
| 3BK || Kenworth (incomplete vehicle)
|-
| 3BM || Motor Coach Industries bus made by DINA S.A.
|-
| 3BP || Peterbilt  (incomplete vehicle)
|-
| 3B3 || Dodge car 1981–2011
|-
| 3B4 || Dodge SUV 1986–1993
|-
| 3B6 || Dodge incomplete vehicle 1981–2002
|-
| 3B7 || Dodge truck 1981–2002
|-
| 3C3 || Chrysler brand car 1981–2011
|-
| 3C3 || Chrysler Group (all brands) car (including Fiat) 2012-
|-
| 3C4 || Chrysler brand MPV 2001–2005
|-
| 3C4 || Chrysler Group (all brands) MPV (including Fiat) 2012-
|-
| 3C6 || Chrysler Group (all brands) truck 2012–
|-
| 3C7 || Chrysler Group (all brands) incomplete vehicle 2012–
|-
| 3C8 || Chrysler brand MPV 2001–2005
|-
| 3CA || Chrysler brand MPV 2001 (PT Cruiser w/serial# 232057-265662)
|-
| 3CE || Volvo Buses de Mexico
|-
| 3CG || KTMMEX S.A. de C.V.
|-
| 3CZ || Honda SUV made by Honda de Mexico
|-
| 3D2 || Dodge incomplete vehicle 2007–2009
|-
| 3D3 || Dodge truck 2006–2009
|-
| 3D4 || Dodge SUV 2009–2011
|-
| 3D6 || Dodge incomplete vehicle 2003–2011
|-
| 3D7 || Dodge truck 2002–2011
|-
| 3EL || ATRO (truck trailer)
|-
| 3E4 || 2011 Fiat SUV (Freemont)
|-
| 3FA || [[../Ford/VIN Codes|Ford]] car
|-
| 3FC || Ford stripped chassis made by Ford &amp; IMMSA
|-
| 3FE || [[../Ford/VIN Codes|Ford]] Mexico
|-
| 3FM || [[../Ford/VIN Codes|Ford]] MPV/SUV
|-
| 3FN || Ford F-650/F-750 made by Blue Diamond Truck Co. (truck)
|-
| 3FR || Ford F-650/F-750 &amp; Ford LCF made by Blue Diamond Truck Co. (incomplete vehicle)
|-
| 3FT || [[../Ford/VIN Codes|Ford]] truck
|-
| 3F6 || Sterling Bullet
|-
| 3G || [[../GM/VIN Codes|General Motors]] Mexico
|-
| 3G0 || Saab 9-4X 2011
|-
| 3G0 || Holden Equinox 2018–2020
|-
| 3G1 || [[../GM/VIN Codes|Chevrolet]] car
|-
| 3G2 || [[../GM/VIN Codes|Pontiac]] car
|-
| 3G4 || [[../GM/VIN Codes|Buick]] car
|-
| 3G5 || [[../GM/VIN Codes|Buick]] SUV
|-
| 3G7 || [[../GM/VIN Codes|Pontiac]] SUV
|-
| 3GA || JAC models assembled by Giant Motors in Mexico
|-
| 3GC || Chevrolet truck
|-
| 3GK || GMC SUV
|-
| 3GM || Holden Suburban
|-
| 3GN || Chevrolet SUV
|-
| 3GP || Honda Prologue EV made by GM
|-
| 3GS || Saturn SUV
|-
| 3GT || GMC truck
|-
| 3GY || Cadillac SUV
|-
| 3H1 || Honda motorcycle/UTV
|-
| 3H3 || Hyundai de Mexico, S.A. de C.V. for Hyundai Translead (truck trailers)
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HA || International Trucks (incomplete vehicle - straight truck) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Blue Diamond Truck Co. 2011-2015
|-
| 3HC || International Trucks (complete vehicle - truck tractor) made by Navistar Mexico/International Motors Mexico 2016-
|-
| 3HD || Acura SUV made by Honda de Mexico
|-
| 3HG || [[../Honda/VIN Codes|Honda]] car made by Honda de Mexico
|-
| 3HR || International Trucks (complete vehicle - truck)
|-
| 3HS || International Trucks &amp; Caterpillar Trucks (complete vehicle - truck tractor)
|-
| 3HT || International Trucks &amp; Caterpillar Trucks (incomplete vehicle - straight truck)
|-
| 3HV || International (incomplete vehicle - bus)  
|-
| 3JB || BRP Mexico (Can-Am ATV/UTV &amp; Can-Am Ryker 3-wheeler)
|-
| 3JC || BRP Mexico (Can-Am Origin &amp; Pulse electric 2-wheel motorcycles)
|-
| 3KM || Kia/Hyundai MPV/SUV made by KMMX
|-
| 3KP || Kia/Hyundai car made by KMMX
|-
| 3LN || Lincoln car
|-
| 3MA || Mercury car (1988-1995)
|-
| 3MD || Mazda de Mexico car (Mazda 2)
|-
| 3ME || Mercury car (1996-2011)
|-
| 3MF || BMW M car
|-
| 3MG || Isuzu Motors de Mexico
|-
| 3MJ || Mazda CX-3 (Mazda de Mexico)
|-
| 3MV || Mazda de Mexico SUV (Mazda CX-30)
|-
| 3MW || BMW car
|-
| 3MY || Toyota car made by Mazda de Mexico Vehicle Operation
|-
| 3MZ || Mazda de Mexico car (Mazda 3)
|-
| 3N1 || Nissan Mexico car
|-
| 3N6 || Nissan Mexico truck &amp; Chevrolet City Express
|-
| 3N8 || Nissan Mexico MPV
|-
| 3NS || Polaris Industries ATV
|-
| 3NE || Polaris Industries UTV
|-
| 3P3 || Plymouth car
|-
| 3PC || Infiniti SUV made by COMPAS
|-
| 3TM || Toyota truck made by TMMBC
|-
| 3TY || Toyota truck made by TMMGT
|-
| 3VV || Volkswagen Mexico SUV
|-
| 3VW || Volkswagen Mexico car
|-
| 3WK || Kenworth truck
|-
| 3WP || Peterbilt truck
|-
| 3X1 || Mack Truck Mexico (truck)
|-
| 3X2 || Mack Truck Mexico (incomplete vehicle)
|-
| 4A3 || Mitsubishi Motors car
|-
| 4A4 || Mitsubishi Motors SUV
|-
| 4B3 || Dodge car made by Diamond-Star Motors factory
|-
| 4B9/038 || BYD Coach &amp; Bus LLC
|-
| 4C3 || Chrysler car made by Diamond-Star Motors factory
|-
| 4C6 || Reinke Manufacturing Company (truck trailer)
|-
| 4C9/272 || Christini Technologies (motorcycle)
|-
| 4C9/561 || Czinger
|-
| 4C9/626 || Canoo Inc.
|-
| 4CD || Oshkosh Chassis Division incomplete vehicle (RV chassis)
|-
| 4DR || IC Bus (complete vehicle - bus)
|-
| 4E3 || Eagle car made by Diamond-Star Motors factory
|-
| 4EN || E-ONE, Inc. (fire engines - truck)
|-
| 4EZ || KZ Recreational Vehicles (trailer)
|-
| 4F2 || Mazda SUV made by Ford
|-
| 4F4 || Mazda truck made by Ford
|-
| 4G1 || Chevrolet Cavalier convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G2 || Pontiac Sunfire convertible made by Genasys L.C. – a GM/ASC joint venture
|-
| 4G3 || Toyota Cavalier made by GM
|-
| 4G5 || General Motors EV1
|-
| 4GD || WhiteGMC Brigadier 1988–1989 made by GM
|-
| 4GD || Opel/Vauxhall Sintra
|-
| 4GL || Buick incomplete vehicle
|-
| 4GT || Isuzu incomplete vehicle built by GM
|-
| 4JG || [[../Mercedes-Benz/VIN Codes|Mercedes-Benz]] SUV
|-
| 4J8 || LBT, Inc. (truck trailer)
|-
| 4KA || IC Bus (complete vehicle - truck)
|-
| 4KB || Chevrolet W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KD || GMC W-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4KL || Isuzu N-Series (gas engine only) made by GM (Incomplete Vehicle - medium duty)
|-
| 4LM || Capacity Trucks (truck) [terminal tractors]
|-
| 4M2 || [[../Ford/VIN Codes|Mercury]] MPV/SUV
|-
| 4M9/220 || Meyers Manx, LLC (Manx 2.0 EV) [Passenger Car - Replica]
|-
| 4ML || Oshkosh Trailer Division
|-
| 4MZ || Buell Motorcycle Company (Mid-1995 – )
|-
| 4N2 || Nissan Quest made by Ford
|-
| 4NU || Isuzu Ascender made by GM
|-
| 4PR || Hughes Trailers of Jackson (trailer)
|-
| 4P1 || Pierce Manufacturing Inc. USA
|-
| 4P3 || Plymouth car made by Diamond-Star Motors factory 1990–1994
|-
| 4P3 || Mitsubishi Motors SUV made by Mitsubishi Motor Manufacturing of America 2013–2015 for export only
|-
| 4RK || Nova Bus &amp; Prevost made by Nova Bus (US) Inc.
|-
| 4S1 || Isuzu truck made by Subaru Isuzu Automotive
|-
| 4S2 || Isuzu SUV made by Subaru Isuzu Automotive &amp; 2nd gen. Holden Frontera made by SIA
|-
| 4S3 || [[../Subaru/VIN Codes|Subaru]] car
|-
| 4S4 || [[../Subaru/VIN Codes|Subaru]] SUV/MPV
|-
| 4S6 || Honda SUV made by Subaru Isuzu Automotive
|-
| 4S7 || Spartan Motors incomplete vehicle 
|-
| 4S9/197 || Smith Electric Vehicles
|-
| 4S9/345 || Satellite Suites (trailer)
|-
| 4S9/419 || Spartan Motors truck
|-
| 4S9/454 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/520 || Signature Autosport, LLC (Osprey Custom Cars)
|-
| 4S9/542 || Scuderia Cameron Glickenhaus SCG Boot (M.P.V.)
|-
| 4S9/544 || Scuderia Cameron Glickenhaus passenger car
|-
| 4S9/559 || Spartan Fire, LLC truck (formerly Spartan ER)
|-
| 4S9/560 || Spartan Fire, LLC incomplete vehicle (formerly Spartan ER)
|-
| 4S9/569 || SC Autosports, LLC (Kandi)
|-
| 4TA || [[../Toyota/VIN Codes|Toyota]] truck made by NUMMI
|-
| 4T1 || [[../Toyota/VIN Codes|Toyota]] car made by Toyota Motor Manufacturing Kentucky
|-
| 4T3 || [[../Toyota/VIN Codes|Toyota]] MPV/SUV made by Toyota Motor Manufacturing Kentucky
|-
| 4T4 || [[../Toyota/VIN Codes|Toyota]] car made by Subaru of Indiana Automotive
|-
| 4T9/208 || Xos, Inc.
|-
| 4T9/228 || Lumen Motors
|-
| 4UF || Arctic Cat Inc.
|-
| 4US || BMW car
|-
| 4UZ || Freightliner Custom Chassis Corporation &amp; &lt;br /&gt; gas-powered Mitsubishi Fuso trucks assembled by Freightliner Custom Chassis &amp; &lt;br /&gt; Thomas Built Buses FS-65 &amp; Saf-T-Liner C2
|-
| 4V0 || Crossroads RV (recreational vehicles)
|-
| 4V1 || WhiteGMC (truck) 1988-1995
|-
| 4V2 || WhiteGMC (incomplete vehicle) 1988-1995
|-
| 4V3 || WhiteGMC (glider) 1988-1995
|-
| 4V1 || Volvo Trucks North America [low cab-over engine] (truck) 2000-2003
|-
| 4V2 || Volvo Trucks North America [low cab-over engine] (incomplete vehicle) 2000-2003
|-
| 4V4 || Volvo Trucks North America [conventional] (truck) 1996+
|-
| 4V5 || Volvo Trucks North America [conventional] (incomplete vehicle)  1996+
|-
| 4V6 || Volvo Trucks North America (glider)
|-
| 4VA || Volvo Trucks North America [conventional- Class 7 w/air brakes] (truck) 1997-1999
|-
| 4VB || Volvo Trucks North America [conventional- Class 7 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VC || Volvo Trucks North America [conventional- Class 7 w/hydraulic brakes] (incomplete vehicle)
|-
| 4VD || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (truck)
|-
| 4VE || Volvo Trucks North America [low cab-over engine- Class 7 w/air brakes] (incomplete vehicle)
|-
| 4VG || Volvo Trucks North America [conventional- Class 8 w/air brakes] (truck) 1997-1999
|-
| 4VH || Volvo Trucks North America [conventional- Class 8 w/air brakes] (incomplete vehicle) 1997-1999
|-
| 4VJ || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VK || Volvo Trucks North America [high cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VL || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (truck)
|-
| 4VM || Volvo Trucks North America [low cab-over engine- Class 8 w/air brakes] (incomplete vehicle)
|-
| 4VZ || Spartan Motors/The Shyft Group (incomplete vehicle – bare chassis only)
|-
| 4WW || Wilson Trailer Sales
|-
| 4W1 || '24+ Chevrolet Suburban HD made by GM Defense for US govt. in Concord, NC
|-
| 4W5 || Acura ZDX EV made by GM
|-
| 4XA || Polaris Inc.
|-
| 4X4 || Forest River
|-
| 4YD || KeyStone RV Company (recreational vehicle)
|-
| 4YM || Carry-On Trailer, Inc.
|-
| 4YM || Anderson Manufacturing (trailer)
|-
| 4Z3 || American LaFrance truck
|-
| 43C || Consulier
|-
| 44K || HME Inc. (fire engines - incomplete vehicle) (HME=Hendrickson Mobile Equipment)
|-
| 46G || Gillig incomplete vehicle
|-
| 46J || Federal Motors Inc
|-
| 478 || Honda ATV
|-
| 480 || Sterling Trucks (truck)
|-
| 49H || Sterling Trucks (incomplete vehicle)
|-
| 5AS || Global Electric Motorcars (GEM) 1999-2011
|-
| 5AX || Armor Chassis (truck trailer)
|-
| 5A4 || Load Rite Trailers Inc.
|-
| 5BP || Solectria
|-
| 5BZ || Nissan &quot;bus&quot; (van with more than 3 rows of seats)
|-
| 5B4 || Workhorse Custom Chassis, LLC incomplete vehicle (RV chassis)
|-
| 5CD || Indian Motorcycle Company of America (Gilroy, CA)
|-
| 5CJ || Western Star Trucks (incomplete vehicle)
|-
| 5CK || Western Star Trucks (truck)
|-
| 5CX || Shelby Series 1
|-
| 5DF || Thomas Dennis Company LLC
|-
| 5DG || Terex Advance Mixer, Inc. (Formerly Advance Mixer, Inc.) (truck)
|-
| 5EH || Excelsior-Henderson Motorcycle
|-
| 5EO || Cottrell (truck trailer)
|-
| 5FC || Columbia Vehicle Group (Columbia, Tomberlin) (low-speed vehicles)
|-
| 5FN || Honda MPV/SUV made by Honda Manufacturing of Alabama
|-
| 5FP || Honda truck made by Honda Manufacturing of Alabama
|-
| 5FR || Acura SUV made by Honda Manufacturing of Alabama 
|-
| 5FT || Feeling Trailers
|-
| 5FY || New Flyer
|-
| 5GA || Buick MPV/SUV
|-
| 5GD || Daewoo G2X
|-
| 5GN || Hummer H3T
|-
| 5GR || Hummer H2
|-
| 5GT || Hummer H3
|-
| 5GZ || Saturn MPV/SUV
|-
| 5G8 || Holden Volt
|-
| 5HD || Harley-Davidson for export markets
|-
| 5HT || Heil Trailer (truck trailer)
|-
| 5J1 || Big Dog Motorcycles (Mid-2002 – )
|-
| 5J5 || Club Car (low-speed vehicle)
|-
| 5J6 || Honda SUV made by Honda of America Mfg. in Ohio
|-
| 5J8 || Acura SUV made by Honda of America Mfg. in Ohio
|-
| 5KB || Honda car made by Honda Manufacturing of Alabama
|-
| 5KJ || Western Star Trucks (truck)
|-
| 5KK || Western Star Trucks (incomplete vehicle)
|-
| 5KM || Vento Motorcycles
|-
| 5KT || Karavan Trailers
|-
| 5L1 || [[../Ford/VIN Codes|Lincoln]] SUV - Limousine (2004–2009)
|-
| 5L5 || American IronHorse Motorcycle
|-
| 5LD || Ford &amp; Lincoln incomplete vehicle – limousine (2010–2014)
|-
| 5LM || [[../Ford/VIN Codes|Lincoln]] SUV
|-
| 5LT || [[../Ford/VIN Codes|Lincoln]] truck
|-
| 5MZ || Buell Motorcycle Company for export markets
|-
| 5N1 || Nissan &amp; Infiniti SUV
|-
| 5N3 || Infiniti SUV
|-
| 5NH || Forest River
|-
| 5NM || Hyundai SUV made by HMMA
|-
| 5NP || Hyundai car made by HMMA
|-
| 5NT || Hyundai truck made by HMMA
|-
| 5PV || Hino incomplete vehicle made by Hino Motors Manufacturing USA
|-
| 5RJ || International MXT made by Android Industries - Springfield LLC
|-
| 5RX || Heartland Recreational Vehicles
|-
| 5S3 || Saab 9-7X
|-
| 5SA || Suzuki Manufacturing of America Corp. (ATV)
|-
| 5SX || American LaFrance incomplete vehicle (Condor)
|-
| 5TB || [[../Toyota/VIN Codes|Toyota]] truck made by TMMI
|-
| 5TD || Toyota MPV/SUV &amp; Lexus TX made by TMMI
|-
| 5TE || Toyota truck made by NUMMI
|-
| 5TF || Toyota truck made by TMMTX
|-
| 5TU || Construction Trailer Specialist (truck trailer)
|-
| 5UM || BMW M car
|-
| 5UX || BMW SUV
|-
| 5VC || Autocar incomplete vehicle
|-
| 5VF || American Electric Vehicle Company (low-speed vehicle)
|-
| 5VK || Great Northern Trailer Works (truck trailer)
|-
| 5VP || Victory Motorcycles
|-
| 5V4 || Autocar truck
|-
| 5V8 || Vanguard National (truck trailer)
|-
| 5WE || IC Bus (incomplete vehicle - bus or truck)
|-
| 5XX || Kia car made by KMMG
|-
| 5XY || Kia/Hyundai SUV made by KMMG
|-
| 5YA || Indian Motorcycle Company (Kings Mountain, NC)
|-
| 5YF || Toyota car made by TMMMS
|-
| 5YJ || Tesla, Inc. passenger car (only used for US-built Model S and Model 3 starting from Nov, 1st 2021)
|-
| 5YM || BMW M SUV
|-
| 5YN || Cruise Car, Inc.
|-
| 5Y2 || Pontiac Vibe made by NUMMI
|-
| 5Y4 || Yamaha Motor Motor Mfg. Corp. of America (ATV, UTV)
|-
| 5ZT || Forest River (recreational vehicles)
|-
| 5ZU || Greenkraft (truck)
|-
| 5Z6 || Suzuki Equator (truck) made by Nissan
|-
| 50E || Lucid Motors passenger car
|-
| 50G || Karma Automotive
|-
| 50H || Norstar Company (truck trailers, truck beds)
|-
| 516 || Autocar truck
|-
| 51R || Brammo Motorcycles
|-
| 51T || Monaco RV LLC/Navistar RV LLC: Monaco (trailer)
|-
| 51U || Monaco RV LLC/Navistar RV LLC: Holiday Rambler 2010- (trailer)
|-
| 51V || Monaco RV LLC/Navistar RV LLC: R-Vision (trailer)
|-
| 51X || Monaco RV LLC/Navistar RV LLC: McKenzie (trailer)
|-
| 51Z || Monaco RV LLC/Navistar RV LLC: Monaco RV [Roadmaster Chassis] (incomplete vehicle) 
|-
| 522 || GreenGo Tek (low-speed vehicle)
|-
| 523 || VPG (The Vehicle Production Group)
|-
| 52C || GEM subsidiary of Polaris Inc.
|-
| 537 || Azure Dynamics Transit Connect Electric
|-
| 538 || Zero Motorcycles
|-
| 53G || Coda Automotive
|-
| 53T || Think North America in Elkhart, IN
|-
| 546 || EBR Motorcycles
|-
| 54C || Winnebago Industries travel trailer
|-
| 54D || Isuzu &amp; Chevrolet commercial trucks built by Spartan Motors/The Shyft Group
|-
| 54F || Rosenbauer Motors (incomplete vehicle)
|-
| 55S || Mercedes-Benz car
|-
| 56E || Armor Lite Trailer Mfg. (truck trailers)
|-
| 56K || Indian Motorcycle International, LLC (Polaris subsidiary)
|-
| 573 || Grand Design RV (truck trailer)
|-
| 57C || Maurer Manufacturing (truck trailer)
|-
| 57R || Oreion Motors
|-
| 57S || Lightning Motors Corp. (electric motorcycles)
|-
| 57W || Mobility Ventures
|-
| 57X || Polaris Slingshot
|-
| 58A || Lexus car made by TMMK (Lexus ES)
|-
| 6AB || MAN Australia
|-
| 6AM || Jayco Corp. (RVs)
|-
| 6F1 || Ford
|-
| 6F2 || Iveco Trucks Australia Ltd.
|-
| 6F4 || Nissan Motor Company Australia
|-
| 6F5 || Kenworth Australia
|-
| 6FM || Mack Trucks Australia
|-
| 6FP || [[../Ford/VIN Codes|Ford]] Australia
|-
| 6G1 || [[../GM/VIN Codes|General Motors]]-Holden (post Nov 2002) &amp; Chevrolet &amp; Vauxhall Monaro &amp; VXR8
|-
| 6G2 || [[../GM/VIN Codes|Pontiac]] Australia (GTO &amp; G8)
|-
| 6G3 || [[../GM/VIN Codes|General Motors]] Chevrolet Caprice PPV &amp; SS performance sedan 2014-2017
|-
| 6H8 || [[../GM/VIN Codes|General Motors]]-Holden (pre Nov 2002)
|-
| 6KT || BCI Bus
|-
| 6MM || Mitsubishi Motors Australia 
|-
| 6MP || Mercury Capri 1991-1994
|-
| 6T1 || [[../Toyota/VIN Codes|Toyota]] Motor Corporation Australia
|-
| 6T9 || Privately Imported car (VIN issued by Victoria) or Trailer in Australia
|-
| 6U9 || Privately Imported car in Australia
|-
| 6Y9/043 || Intertruck Distributors (NZ) Ltd. - International Trucks New Zealand
|-
| 6ZZ || Privately Imported car in Australia
|-
| 7AB || MAN New Zealand
|-
| 7AT || VIN assigned by the New Zealand Transport Authority Waka Kotahi from 29 November 2009
|-
| 7A1 || Mitsubishi New Zealand
|-
| 7A3 || Honda New Zealand
|-
| 7A4 || Toyota New Zealand
|-
| 7A5 || Ford New Zealand
|-
| 7A7 || Nissan New Zealand
|-
| 7A8 || VIN assigned by the New Zealand Transport Authority Waka Kotahi before 29 November 2009
|-
| 7B2 || Nissan Diesel bus New Zealand
|-
| 7FA || Honda SUV made by Honda Manufacturing of Indiana
|-
| 7FC || Rivian truck
|-
| 7F7 || Arcimoto, Inc. 
|-
| 7GZ || GMC incomplete vehicles (Savana cutaway) made by Navistar International/International Motors
|-
| 7G0 || Faraday Future
|- 
| 7G2 || Tesla, Inc. truck (used for Nevada-built Semi Trucks &amp; Texas-built Cybertruck)
|- 
| 7H4 || Hino truck
|-
| 7H8 || Cenntro Electric Group Limited low-speed vehicle
|- 
| 7JD || Volvo Cars SUV
|- 
| 7JR || Volvo Cars passenger car
|- 
| 7JS || White River Marine Group (trailer)
|- 
| 7JZ || Proterra From mid-2019 on
|- 
| 7KG || Vanderhall Motor Works
|- 
| 7KY || Dorsey (truck trailer)
|-
| 7MM || Mazda SUV made by MTMUS (Mazda-Toyota Joint Venture)
|- 
| 7MU || Toyota SUV made by MTMUS (Mazda-Toyota Joint Venture)
|-
| 7MW || Cenntro Electric Group Limited truck
|-
| 7MZ || HDK electric vehicles
|-
| 7NA || Navistar Defense/ND Defense
|- 
| 7NY || Lordstown Motors
|- 
| 7PD || Rivian SUV
|- 
| 7RZ || Electric Last Mile Solutions
|- 
| 7SA || Tesla, Inc. (US-built MPVs (e.g. Model X, Model Y))
|-
| 7SU || Blue Arc electric trucks made by The Shyft Group
|-
| 7SV || [[../Toyota/VIN Codes|Toyota]] SUV made by TMMTX
|-
| 7SX || Global Electric Motorcars (WAEV) 2022-
|- 
| 7SY || Polestar SUV
|-
| 7TN || Canoo
|-
| 7UU || Lucid Motors MPV/SUV
|-
| 7UZ || Kaufman Trailers (trailer)
|-
| 7VV || Ree Automotive
|-
| 7WA || Scout Motors (MPV)
|-
| 7WE || Bollinger Motors incomplete vehicle
|-
| 7XB || Denago EV Corporation (Low-Speed Vehicle)
|-
| 7YA || Hyundai MPV/SUV made by HMGMA
|-
| 7ZJ || Meyers Manx, LLC (Manx EV Resorter) [Low Speed Vehicle]
|-
| 7Z0 || Zoox
|-
| 71T || Slate Auto (truck)
|-
| 71V || Slate Auto (MPV)
|-
| 722 || Isuzu North America Corp. (incomplete vehicle - medium duty)
|-
| 8AB || Mercedes Benz truck &amp; bus (Argentina)
|-
| 8AC || Mercedes Benz vans (for South America)
|-
| 8AD || Peugeot Argentina
|-
| 8AE || Peugeot van
|-
| 8AF || [[../Ford/VIN Codes|Ford]] Argentina
|-
| 8AG || [[../GM/VIN Codes|Chevrolet]] Argentina
|-
| 8AJ || [[../Toyota/VIN Codes|Toyota]] Argentina
|-
| 8AK || Suzuki Argentina
|-
| 8AN || Nissan Argentina
|-
| 8AP || Fiat Argentina
|-
| 8AT || Iveco Argentina
|-
| 8AW || Volkswagen Argentina
|-
| 8A1 || Renault Argentina
|-
| 8A3 || Scania Argentina
|-
| 8A7 || Minarelli S.A.
|-
| 8BB || Agrale Argentina S.A.
|-
| 8BC || Citroën Argentina
|-
| 8BN || Mercedes-Benz incomplete vehicle (North America)
|-
| 8BR || Mercedes-Benz &quot;bus&quot; (van with more than 3 rows of seats) (North America)
|-
| 8BT || Mercedes-Benz MPV (van with 2 or 3 rows of seats) (North America)
|-
| 8BU || Mercedes-Benz truck (cargo van with 1 row of seats) (North America)
|-
| 8CH || Honda motorcycle
|-
| 8C3 || Honda car/SUV
|-
| 8G1 || Automotores Franco Chilena S.A. Renault
|-
| 8GD || Automotores Franco Chilena S.A. Peugeot
|-
| 8GG || [[../GM/VIN Codes|Chevrolet]] Chile
|-
| 8LD || General Motors OBB - Chevrolet Ecuador
|-
| 8LF || Maresa (Mazda)
|-
| 8LG || Aymesa (Hyundai Motor &amp; Kia)
|-
| 8L4 || Great Wall Motors made by Ciudad del Auto (Ciauto)
|-
| 8XD || Ford Motor Venezuela
|-
| 8XJ || Mack de Venezuela C.A.
|-
| 8XV || Iveco Venezuela C.A.
|-
| 8Z1 || General Motors Venezolana C.A.
|-
| 829 || Industrias Quantum Motors S.A. (Bolivia)
|-
| 9BD || Fiat Brazil &amp; Dodge, Ram made by Fiat Brasil
|-
| 9BF || [[../Ford/VIN Codes|Ford]] Brazil
|-
| 9BG || [[../GM/VIN Codes|Chevrolet]] Brazil
|-
| 9BH || Hyundai Motor Brasil
|-
| 9BM || Mercedes-Benz Brazil car, SUV, commercial truck &amp; bus
|-
| 9BN || Mafersa
|-
| 9BR || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 9BS || Scania Brazil
|-
| 9BU ||Gurgel Motores S.A. (defunct Brazilian automaker)
|-
| 9BV || Volvo Trucks Brazil
|-
| 9BW || Volkswagen Brazil
|-
| 9BY || Agrale S.A.
|-
| 9C2 || Moto Honda Da Amazonia Ltda.
|-
| 9C6 || Yamaha Motor Da Amazonia Ltda.
|-
| 9CD || Suzuki (motorcycles) assembled by J. Toledo Motos do Brasil
|-
| 9DF || Puma
|-
| 9DW || Kenworth &amp; Peterbilt trucks [incomplete vehicle] made by Volkswagen do Brasil
|-
| 9EZ || homemade or handbuilt vehicles
|-
| 92H || Origem Brazil
|-
| 932 || Harley-Davidson Brazil
|-
| 935 || Citroën Brazil
|-
| 936 || Peugeot Brazil
|-
| 937 || Dodge Dakota
|-
| 93C || Chevrolet SUV [Tracker] or pickup [Tornado, Montana, S10] (sold in Mexico, made in Brazil)
|-
| 93H || [[../Honda/VIN Codes|Honda]] Brazil car/SUV
|-
| 93K || Volvo Trucks Brazil
|-
| 93P || Volare
|-
| 93S || Navistar International
|-
| 93R || [[../Toyota/VIN Codes|Toyota]] Brazil
|-
| 93U || Audi Brazil 1999–2006
|-
| 93W || Fiat Ducato made by Iveco 2000–2016
|-
| 93V || Navistar International
|-
| 93X || Souza Ramos – Mitsubishi Motors / Suzuki Jimny
|-
| 93Y || Renault Brazil
|-
| 93Z || Iveco
|-
| 94D || Nissan Brazil
|-
| 94N || RWM Brazil
|-
| 94T || Troller Veículos Especiais
|-
| 95P || CAOA Hyundai &amp; CAOA Chery
|-
| 95V || Dafra Motos (motorscooters from SYM) &amp; Ducati, KTM, &amp; MV Agusta assembled by Dafra
|-
| 95V || BMW motorcycles assembled by Dafra Motos 2009–2016
|-
| 95Z || Buell Motorcycle Company assembled by Harley-Davidson Brazil
|-
| 953 || VW Truck &amp; Bus / MAN Truck &amp; Bus
|-
| 96P || Kawasaki
|-
| 97N || Triumph Motorcycles Ltd.
|-
| 988 || Jeep, Ram [Rampage], and Fiat [Toro] (made at the Goiana plant)
|-
| 98M || BMW car/SUV
|-
| 98P || DAF Trucks
|-
| 98R || Chery
|-
| 99A || Audi 2016-
|-
| 99H || Shineray
|-
| 99J || Jaguar Land Rover
|-
| 99K || Haojue &amp; Kymco assembled by JTZ Indústria e Comércio de Motos
|-
| 99L || BYD
|-
| 99Z || BMW Motorrad (Motorcycle assembled by BMW 2017-)
|-
| 9FB || Renault Colombia (Sofasa)
|-
| 9FC || Compañía Colombiana Automotriz S.A. (Mazda)
|-
| 9GA || [[../GM/VIN Codes|Chevrolet]] Colombia (GM Colmotores S.A.)
|-
| 9UJ || Chery assembled by Chery Socma S.A. (Uruguay)
|-
| 9UK || Lifan (Uruguay)
|-
| 9UT || Dongfeng trucks made by Nordex S.A.
|-
| 9UW || Kia made by Nordex S.A.
|-
| 9VC || Fiat made by Nordex S.A. (Scudo, 2025 Titano)
|-
| 9V7 || Citroen made by Nordex S.A. (Jumpy)
|-
| 9V8 || Peugeot made by Nordex S.A. (Expert)
|}

==References==
{{reflist}}
{{BookCat}}</text>
      <sha1>h6hgn57uafzx44kfa5u0u0pa9qlvjc7</sha1>
    </revision>
  </page>
  <page>
    <title>User talk:JMBryant</title>
    <ns>3</ns>
    <id>158699</id>
    <revision>
      <id>4657127</id>
      <parentid>4642696</parentid>
      <timestamp>2026-08-11T06:50:37Z</timestamp>
      <contributor>
        <username>JMBryant</username>
        <id>90135</id>
      </contributor>
      <comment>/* */ Reply</comment>
      <origin>4657127</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="5745" sha1="o0ok47necux9uza63f1hh5l15uz3ui7" xml:space="preserve">&lt;div font-size:110%; font-weight:bold;&quot;&gt;[[Wikibooks:Welcome|Welcome]] to Wikibooks, JMBryant!&lt;/div&gt;
{| cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; style=&quot;margin:0em 0em 1em 0em; width:100%&quot;
| style=&quot;width:45%; vertical-align:top; border:1px solid #fad67d; background-color:#faf6ed;&quot; |
&lt;div style=&quot;border-bottom:1px solid #fad67d; background-color:#faecc8; padding:0.2em 0.5em 0.2em 0.5em; font-size:110%; font-weight:bold;&quot;&gt;[[Image:Crystal Clear app korganizer.png|20px]] '''First steps tutorial'''&lt;/div&gt;
&lt;div style=&quot;border-bottom:1px solid #fad67d; padding:0.4em 1em 0.3em 1em;&quot;&gt;
'''Wikibooks is for freely-licensed collaboratively-developed [[WB:WIW|textbooks]].'''&lt;br/&gt;You don't need technical skills in order to contribute here. '''[[WB:BOLD|Be bold]]''' contributing here and ''[[WB:AGF|assume good faith]]'' for the intentions of others. Remember, this is a ''[[w:wiki|wiki]]'', so you're allowed to change just about anything &amp; it is really easy. Come say [[WB:HELP|hello]] to everyone!
&lt;/div&gt;
&lt;div style=&quot;border-bottom:1px solid #fad67d; background-color:#faecc8; padding:0.2em 0.5em 0.2em 0.5em; font-size:110%; font-weight:bold;&quot;&gt;[[Image:Icon apps query.svg|20px]] '''Getting help'''&lt;/div&gt;
&lt;div style=&quot;padding:0.4em 1em 0.3em 1em;&quot;&gt;
* You can always get help from the community in the [[Wikibooks:Reading room|Reading room]] or in our [[irc:wikibooks|IRC channel]].
* If something you wrote was tagged with {{tlx|query}}, and you think this was done in error, just remove it &amp; explain why on the talk page.
* If your upload was tagged with {{tlx|nld}}, {{tlx|bfu}}, or {{tlx|nfur}}, please read the template message as it explains the violation of [[WB:MEDIA|our media policy]]. Please be sure to provide the required {{tlx|information}}: a [[WB:ICT|license tag]] &amp; source are always required; fair use images require a {{tlx|fair use rationale}}.&lt;/div&gt;
| style=&quot;padding:0em 0.5em 0em 0.5em;&quot; |

| style=&quot;width:55%; vertical-align:top; border:1px solid #abd5f5; background-color:#f1f5fc;&quot; |
&lt;div style=&quot;border-bottom:1px solid #abd5f5; background-color:#d0e5f5; padding:0.2em 0.5em 0.2em 0.5em; font-size:110%; font-weight:bold;&quot;&gt;[[Image:Transmission icon.png|20px]] '''Goodies, tips and tricks'''&lt;/div&gt;
&lt;div style=&quot;border-bottom:1px solid #abd5f5; padding:0.4em 1em 0.3em 1em;&quot;&gt;
* Please [[:w:Wikipedia:Sign your posts on talk pages|sign your name]] on discussion pages by typing &amp;#126;&amp;#126;&amp;#126;&amp;#126;
* If you're coming here from Wikipedia, you should read [[WB:WFW|our primer for Wikipedians]] to get up-to-speed quickly.
* '''Please make sure you follow our [[WB:NP|naming policy]]''' - modules should be named like &lt;tt&gt;Book Title/Chapter Title&lt;/tt&gt;.
* User scripts can make many tasks easier. Look at the ''Gadgets'' tab of [[Special:Preferences|''my preferences'']]; check off the boxes for the scripts you want, and hit ''save''!
&lt;/div&gt;
&lt;div style=&quot;border-bottom:1px solid #abd5f5; background-color:#d0e5f5; padding:0.2em 0.5em 0.2em 0.5em; font-size:110%; font-weight:bold;&quot;&gt;[[Image:Nuvola filesystems trashcan full.png|20px]] '''Made a mistake?'''&lt;/div&gt;
&lt;div style=&quot;border-bottom:1px solid #abd5f5; padding:0.4em 1em 0.3em 1em;&quot;&gt;
* Need to rename a page? Use the ''move'' tab (only become available once your account is 4 days old - until then, ask for [[WB:HELP|help]]).
* To get a page deleted, add {{tlx|delete|''your reason for requesting deletion''}} to the top of the page.
* If something you wrote was deleted, please read the [[WB:DP|deletion policy]], and check the [[Special:Log/delete|deletion log]] to find out why. Also check the [[WB:VFD|VFD]] archives if applicable. You can request undeletion at [[WB:VFU]].
&lt;/div&gt;
&lt;div style=&quot;background-color:#transparent; padding:0.2em 0.5em 0.2em 0.5em;&quot;&gt;Thanks &amp;nbsp;'''&amp;ndash;&amp;nbsp;[[User:Mike.lifeguard|&lt;span style=&quot;color: Indigo;&quot;&gt;Mike.lifeguard&lt;/span&gt;]]'''&amp;nbsp;&amp;#124;&amp;nbsp;&lt;sup&gt;[[User talk:Mike.lifeguard|&lt;span style=&quot;color: Indigo;&quot;&gt;talk&lt;/span&gt;]]&lt;/sup&gt; 14:11, 25 May 2008 (UTC)&lt;/div&gt;
|-
|align=right colspan=3|&lt;small&gt;(P.S. Would you like to provide [[Template talk:Bigwelcome|feedback]] on this message?)&lt;/small&gt;
|}


{{mbox|type=warning|msg='''Wikibooks regretfully cannot accept [[Wikibooks:Copyrights|copyrighted]] materials.'''&lt;br/&gt;We [[Wikibooks:Welcome, newcomers|welcome]] and appreciate your contributions. If [[:Cookbook:Bambi Bolognaise]] uses an acceptable copyleft license or the copyright holders are willing to give [[Wikibooks:Boilerplate_request_for_permission|permission]] to use it under an acceptable copyleft license, then we need you to include the licensing information with it. Please read [[Wikibooks:Media]] to learn more about our requirements. After 7 days if this is not addressed appropriately we will have to delete it [[WB:COPYVIO|per policy]]. If you have any questions you can ask me personally or ask in the [[WB:HELP|reading room]]. Thank you; Happy editing! &amp;nbsp;'''&amp;ndash;&amp;nbsp;[[User:Mike.lifeguard|&lt;span style=&quot;color: Indigo;&quot;&gt;Mike.lifeguard&lt;/span&gt;]]'''&amp;nbsp;&amp;#124;&amp;nbsp;&lt;sup&gt;[[User talk:Mike.lifeguard|&lt;span style=&quot;color: Indigo;&quot;&gt;talk&lt;/span&gt;]]&lt;/sup&gt; 14:10, 25 May 2008 (UTC)}}
:The recipe at &lt;http://www.italiansrus.com/recipes/bolognaisesauce.htm&gt; is MY recipe, contributed to them by me. I did not transfer my copyright, which I still own.  James Bryant
::I need you to email permissions-en@wikimedia.org to verify this. &amp;nbsp;'''&amp;ndash;&amp;nbsp;[[User:Mike.lifeguard|&lt;span style=&quot;color: Indigo;&quot;&gt;Mike.lifeguard&lt;/span&gt;]]'''&amp;nbsp;&amp;#124;&amp;nbsp;&lt;sup&gt;[[User talk:Mike.lifeguard|&lt;span style=&quot;color: Indigo;&quot;&gt;talk&lt;/span&gt;]]&lt;/sup&gt; 14:11, 25 May 2008 (UTC)
:Eventually done, FWIW.
:Cancer disrupts life.
:JMB [[User:JMBryant|JMBryant]] ([[User talk:JMBryant|discuss]] • [[Special:Contributions/JMBryant|contribs]]) 06:50, 11 August 2026 (UTC)</text>
      <sha1>o0ok47necux9uza63f1hh5l15uz3ui7</sha1>
    </revision>
  </page>
  <page>
    <title>Wing Chun Forms/Siu Nim Tau</title>
    <ns>0</ns>
    <id>165889</id>
    <revision>
      <id>4657112</id>
      <parentid>4436697</parentid>
      <timestamp>2026-08-10T22:55:51Z</timestamp>
      <contributor>
        <username>CommonsDelinker</username>
        <id>49843</id>
      </contributor>
      <comment>Removing [[:c:File:The_age_of_18_Bruce_Lee_and_Ye_Wen.jpg|The_age_of_18_Bruce_Lee_and_Ye_Wen.jpg]], it has been deleted from Commons by [[:c:User:Infrogmation|Infrogmation]] because: per [[:c:Commons:Deletion requests/File:The age of 18 Bruce Lee and Ye W</comment>
      <origin>4657112</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="20300" sha1="1x1lo9onn8jf8oeykjytxb4gogv8rks" xml:space="preserve">&lt;div style=&quot;float:right;margin:0px 0px 10px 10px&quot;&gt;__TOC__&lt;/div&gt;[[File:SiGung Keko doing Siu Nim Tao 2014-06-09 12-50.jpeg|thumb]]Siu Nim Tau teaches Wing Chun concepts and basic techniques. Without the foundation provided by the concepts, you will not master Wing Chun. The techniques are useful in an unarmed fight.

==Opening==
In this part you learn the proper height and width of your stance.

===Applications===
*The Wing Chun basic stance is not a fighting posture&amp;mdash;unless you fight with your hands in your armpits&amp;mdash;but does demonstrate most of the basics that go into a proper fighting posture. Your weight is balanced in all directions, and you are ready to move in any direction. Your feet are far enough apart that you can't be pushed over easily. With your knees together you can protect your groin against kicks and knees. Your torso is upright and you are looking straight ahead. Your hands are up high enough that it takes some effort to keep them there. Even though they aren't doing anything useful right now, you have to pay attention to keep your hands in position. See the Chum Kiu form's write-up for for discussion of stances.

===Training Tips===
*Once you find your proper posture, keep your legs and torso in position throughout the form. Only your arms move in Siu Nim Tau.
#Start by standing straight with your head up, feet together, toes pointing forward, and hands at your sides. It's a loose position of attention.
#Raise your arms forward, keeping them straight, until they are at shoulder level. Form your hands into loose fists.
#Bring your hands back to the &quot;rest&quot; position, with your fists alongside your chest and almost up to your armpits. The elbows are pointing straight back and the forearms are level with the ground. Keep your torso upright throughout.
#While you are moving your arms back, get your legs into the horse stance. Bend your knees. Point your toes out, then swing your heels out. Your feet should be shoulder width apart when you are done, with the toes pointing inward. When you are in horse stance, your weight is evenly balanced left and right and forward and back. Your knees are slightly together.

==Establish Centerline==
#Double Gahn Sau, stopping with wrists together centered in front of your body. Wrists should be near waist level. Left wrist in front of right.
#Without separating wrists, raise and rotate arms to chest level, palms up. Left wrist on top of right.
#Return hands to rest position.

==Centerline Punch==
#Bring left fist to the center of your chest, about a fist and a half in front of the chest. Knuckles are up-and-down, with the wrist slightly cocked so the pinky, ring, and middle knuckles form a flat hitting surface. Keep arm muscles relaxed.
#Punch forward with the left hand. Hand moves straight forward, directly in front of your breastbone and a little below shoulder height. Punch quickly but keep your arm relaxed until the last six inches of the punch, then snap the hand forward with power. To properly execute the Wing Chun punch the arm '''must''' extend fully. Due to the slightly upward motion of the travelling fist the full extension of the arm does not damage the elbow joint if performed correctly. If there is a slight downward arcing of the fist (like with a hammer fist or backfist style strike) then the full extension of the arm will damage the elbow joint (locking out). This is how it is taught from the Ip Man -&gt; Ip Chun lineage. One can visualise this by a darts player throwing one of his darts. The arm moves to full extension in the correct motion without damaging the elbow joint.
#*''Tip'': Punch in the air to practice the motions. You can see and practice the movement more clearly if your hand isn't hitting anything.
#*''Tip'': Punch a heavy bag. After your technique is good, it's important to practice punches against a real target. It's much harder to keep the punches going so you will improve your strength and endurance. You will also train your hands and arms to take the impact. Practicing only in the air trains your muscles to pull the punch before impact, which is bad technique in a fight or competition.
#*''Tip'': Do not punch through the target. Any energy used pushing the target away is wasted and all energy should be directed toward the centre of the opponent, not through them. This is converse to styles such as Karate where breaking is practiced and one must punch through the brick. Ip-Chun demonstrates this by punching a melon. Upon opening the melon the inside is found to have become pulp.
#*''Tip'': Keep elbow in when punching. This uses the power of the large muscles of your chest. Demonstrate this by holding your fist in centerline and having someone push it toward you. Compare with pushing against your fist with your arm to the side with your elbow out&amp;mdash;a hook punch. The leg, hip and back shape is of paramount importance in absorbing the oncoming force, not just the upper body. One must make sure the entire body posture is correct in order to direct components of the oncoming force into the ground.
#*''Tip'': Three inch punch. Your arm should stay relaxed until just before impact. The power of a Wing Chun punch comes from contracting your arm muscles in the last few inches, plus shifting to put your torso's and legs' muscles into it. In training yourself to punch correctly, begin with nine-inch punches. Practice keeping your arm relaxed for most of the distance, only contracting at the end. Once you have the technique down, perform three-inch punches, contracting your muscles the entire distance. Enhance the punch by shifting into it. Advanced practitioners can work on performing one-inch punches and still put decent power into them.
#*''Tip'': Practice palm and finger strikes. The mechanics of a palm or finger strike are almost the same as for a punch. Wing Chun has four palm strikes, all demonstrated in Siu Nim Tau, and several finger strikes, of which only the eye gouge is demonstrated in Siu Nim Tau.
#Open the hand. Circle the hand around, then return to the rest position.
#*''Tip'': For the form, pause after the punch to highlight each movement. When practicing punches outside the form, and especially when sparring or fighting, pull your hand back after striking. If you leave your hand sticking out there, it can be grabbed.
#Repeat with the right hand.

==Chi Sau==
===Training Tips===
*Perform this section slowly. It should take at least thirty seconds, and thirty minutes is not unreasonable. (Yes, your arms will be tired after holding them out for fifteen minutes each. That's part of the reason for doing it so slowly.)
*Breathe normally
*As you move your arms, do not move your shoulders.
#Tan Sau with left hand, coming to centerline by the time it's extended.
#Huen Sau, then bring left hand back in a Jut Sau along centerline until it's about a fist in front of your chest.
#*''Tip'': Think of the elbow pulling your hand back. Jut Sau is done with a jerking motion, with the wrist performing the block.
#Relax left hand into a Fuk Sau and extend along centerline.
#*''Tip'': Think of the hand pulling the arm forward. This simulates riding along the opponent's arm as he retracts it.
#Huen Sau and Jut Sau as before.
#Fuk Sau as before.
#Jut Sau as before.
#Turn left hand so fingers point upward and palm is to the right. Bring hand to left shoulder then return to centerline. Extend hand forward in an upper palm strike. Turn palm up, Huen Sau, then return left hand to rest position.
#*''Application'': Use your arm when doing the palm strike to control your opponent's arm. Compare elbow position with the spade hand and choose a strike according to where your opponent's arm is.
#*''Note'': It's traditional to wu sau to your opposite shoulder. We have you go to the same shoulder because an outer wu sau combined with an upper palm strike control the opponent's arm better.
#Repeat with the right hand.

==Defend All-Around==

===Applications===
You can defend all around yourself without turning to face the attacker.

#Left hand Gum Sau next to the left hip.
#Right hand Gum Sau next to the right hip.
#Both hands strike diagonally down and backward behind waist.
#*''Application'': This can be a bladder strike against someone close behind you.
#*''Application'': The Gum Saus to the sides followed by the rear strike can break a grab around the waist from the rear.
#Perform a double Gum Sau to the front.
#*''Application'': As with most double-arm motions in Wing Chun forms, the double Gum Sau is for stylistic reasons. In a fight you will normally block with one hand while attacking with the other.
#Bring forearms horizontally up in front of face, left over right, with left hand pointing to the right and right hand pointing to the left.
#Extend arms to the sides, fingers pointed for maximum reach.
#*''Application'': This can be a block, an attack, or a &quot;keep away&quot; move.
#Bring forearms horizontally in front of face, right over left.
#*''Application'': Changing from left over right to right over left suggests the technique of pressing your opponent's arms against his chest with one arm while striking him high with the other. After the strike, drop that hand to cover the opponent's arms and strike with the formerly covering arm.
#Drop elbows and move hands forward into a double Jong Sau.
#*''Application'': Jong Sau, or Structure Hand, is the forward half of Wing Chun's Ready stance. (The rear half is Wu Sau.)
#*''Application'': Jong Sau can block an incoming centerline strike merely by being along centerline. The opponent will to go through or around your arm to hit you.
#Turn both palms up in a double Tok Sau.
#*''Application'': Tok Sau, or Elbow Lifting Hand, is used when your blocking hand is below an incoming high punch. It is a soft alternative to the hard High Bong Sau block of a hook punch.
#Turn both palms down.
#*''Application'': The arms are in the ending position of Biu Sau. Similar to Jong Sau, Biu Sau can block simply by being in the way of a punch. Biu Sau also works similarly to Tan Sau, with much of the effectiveness coming from forward motion.
#Double downward wrist block.
#*''Application'': Wrist blocks are an advanced technique because they require greater precision and power than the basics.
#*''Application'': See also Bil Jie for more applications of wrist blocks.
#Thrust fingers forward in an eye strike.
#*''Application'': one-two with a block and a strike
#Low double wrist block. (TODO - figure out the Chinese name)
#Double monkey paw strike.
#*''Application'': The monkey paw strike is similar to an upper-cut punch. It doesn't have as much power, but it has slightly longer range. Arm and elbow position are slightly different, so it might be faster to go from a block to a monkey paw rather than to an upper cut.
#Return hands to rest position.

==Wu Sau==

===Applications===
*Rear guard hand in case you miss with the front hand.
*Follow up a defensive move with an attack.

#Left hand Wu Sau to right shoulder. Return hand to centerline.
#Left hand spade hand to the front. Palm up, Huen Sau, then return to rest.
#*''Application'': You can use your striking arm to control your opponent's arm after you deflect his punch.
#Repeat with other hand.

==Tan Sau==
[[File:Wing Chun tan sao fist.jpg|thumb]]Cover different areas with minimal motion.

===Applications===
If your hand is high and you need to block a low strike, you can move just your forearm and hand and still cover the low area. More generally, this section demonstrates the principle of using as little effort as possible to attack and defend.

#Perform a Tan Sau with left hand, bringing hand to shoulder height.
#*''Tip'': Do not shift with the Tan Sau.
#*''Application'': Tan Sau blocks medium-to-high strikes coming from the front. The useful range is from the middle of the ribs to the top of the head.
#*''Application'': Tan Sau is often performed with a shift toward the blocking hand or with a side step away from the blocking hand. The combination of block and movement will keep you from being hit by even a powerful strike.
#*''Application'': Tan Sau is often performed with a punch with the other hand.
#Without moving anything except the left forearm, perform a left hand Gahn Sau.
#*''Application'': Gahn Sau blocks low hand strikes, from around the bottom of the ribs to around hip level.
#*''Application'': Gahn Sau is normally performed with a shift toward the blocking hand.
#Without moving anything except the left forearm, perform a left hand Tan Sau.
#*''Note'': This isn't a &quot;real&quot; Tan Sau because the arm is moving outward, not forward. The principle of Immovable Elbow is the key point.
#Huen Sau with the left hand, going from palm up to palm forward with the fingers to the left.
#Perform a left hand Side Palm Strike at rib level. Turn palm up, Huen Sau, and return left hand to rest position.
#*''Application'': It is not necessary to bring the hand back from Tan Sau position before performing the side palm strike. Beginners may wish to get the extra travel distance to gain power, but you should practice to develop power with as little travel as possible. See &quot;Three-inch Punch&quot;, above.
#Repeat the section with the right hand.

==Bong Sau==
[[File:Wing-chun-bong-wu-outline.jpg|thumb]]Demonstrate how to flow around a strong attack.

===Applications===
*Relieving pressure. Because Wing Chun is usable by a smaller person against a larger, stronger one, an important principle is flowing around the opponent's strength. This is called relieving pressure. When an attack is too strong for you to block, shift, get to the other side of the strike, and let it flow past you.
*Bong Sau and Tan Sau easily flow into each other. If a punch is breaking down your Bong Sau structure, pivot the arm around the contact point to a Tan Sau and shift to facing the other way. Your new Tan Sau should steer the punch past you.

#Left hand Bong Sau. Right hand stays in rest position. Don't shift or otherwise move.
#*''Application'': The Bong Sau doesn't lend itself to a strike with the other hand. Normally you will use a Bong Sau just long enough to deflect a strike, then shift into something else. (&quot;Bong Sau comes and goes like the wind.&quot;) You may also kick while blocking.
#Left hand rolls into Tan Sau. Shoulder and wrist don't move.
#*''Application'': You can use a Bong Sau to relieve pressure from a Tan Sau as well.
#*''Application'': When actually relieving pressure from a strike, you normally shift or step to get your body out of the way. 
#After a slight pause, drop fingers and do a left hand Low Palm Strike. Palm up, Huen Sau, return left hand to rest position.
#*''Tip'': The pause is partly to point out that the Tan Sau and the Low Palm Strike are separate moves. The pause also allows you to get your hand into proper position for a hard strike and to focus your intention.
#Repeat with right hand

==Low Clearing==

===Applications===
*Relieve pressure
*Break a wrist grab
*Low block
*Attack after defensive move

#Left arm Gahn Sau, stopping with the wrist at centerline.
#*''Application'': Normally you would shift along with the block. For purposes of the form, do not shift.
#Place outer edge of right hand at outer side of left elbow, palm up. Simultaneously do four things: pull left arm to the left; twist left hand so it's palm up; scrape right hand down left forearm; rotate right hand to palm down.
#*''Application'': The simultaneous move-and-twists are for escaping a grab. If you can, start breaking the grab before it's firm on your arm; it's much harder to get away from a grip than from a reach.
#Repeat, switching left and right.
#Repeat the first way.
#Three quick centerline punches, left right left.
#*''Tip'': Thousand punches: Perform 100 punches, alternating hands. Leave a slight pause between each punch. After the 100, shake it out and rest a moment. Then perform 200 punches, two at a time. Punches can alternate hands or be with the same hand. If you punch twice in a row with the same hand, make sure each punch has proper form and each punch has a snap. After the 100 sets of two, shake it out and rest a moment. Then perform 300 punches, 100 sets of three. Rest. Then perform 400 punches, 100 sets of four. This exercise trains you to punch rapidly yet forcefully&amp;mdash;very useful in competition or fights. Don't start practicing this until you have good form for your punch. Otherwise you'll just be practicing bad form.
#*''Application'': Multiple attacks&amp;mdash;don't rely on a single powerful strike.
#*''Application'': More generally, Wing Chun does not rely on size or power to block or strike. If a move cannot be successfully performed by a small woman against a large man, it's not being done right.

==Closing==
#Bring your hands back from punching position and cross your wrists in front of your chest. Continue bringing your fists back, up, and forward, dropping your elbows as you do so. Bring your fists back to the rest position. At the same time straighten your legs, bring your left foot to the right, and push your hands down past your hips. You will end up in a loose position of attention, the same as the starting position and a few inches to the right.

==Training Tips==
*Perform the form with the &quot;warrior mind&quot;. Think of how to apply each move. Imagine an attack coming and picture yourself blocking it. Most importantly, don't simply go through the form's motions while you're thinking about work or your favorite TV show.
*Once you have learned Siu Nim Tau, practice it in different positions. Practicing in deep horse stance is an obvious variant, strengthening your legs without needing other changes. Doing the form while sitting lets you get practice in when you have a few minutes to kill. It also trains you to fight while sitting, which is a useful skill.

==Key Points==
*Wing Chun forms are textbooks, not mock fights. While the forms in many other martial arts run through a series of moves as if you were going against an opponent, Wing Chun forms simply demonstrate the concepts and basic moves of the style. If you're ever practicing or looking for holes in your personal style, go back to the forms. Look for basic moves that you're leaving out. Review your technique in light of the concepts.
*Wing Chun is designed so a smaller person can defeat a larger, stronger attacker. Most techniques are designed around this principle: flow around the opponent, using soft blocks rather than hard, relieving pressure rather than resisting it, using many lighter punches rather than a single fight-ending power punch. If a technique will not work for a smaller person fighting against a larger, it's not Wing Chun.
*There are several difficulties in Siu Nim Tau. First of all, this is the first Wing Chun form you learn. Many Wing Chun concepts, such as center line theory, are not common. Whether or not you have other martial arts experience, it may take a while to fit these concepts into your style.
*Wing Chun has a great many blocks. Many of them are variations on a theme, and almost all of them work on the principle of gently steering an opponent's attack away from center line. Which block to use depends on where the attack is coming from and where your hands are in relation to the attack. You do not plan ahead to use a Bong Sau followed by a Tok Sau to block the next two attacks; you use whatever block comes naturally from positioning.
*Performing Siu Nim Tau is both easy and difficult. It is easy compared to other forms&amp;ndash;no jumping, no difficult timing between moves. On the other hand, the form is so clean and straightforward that every move has to be precise, a balance between crispness and smooth flow. If you are performing in front of an experienced practitioner, you'll have to be good. Any mistakes will be obvious because there is nothing to distract the audience.
*Wing Chun is not a &quot;sided&quot; style. All moves in Siu Nim Tau are performed with each hand, either simultaneously or one after the other. (Normally they will not be performed simultaneously outside the form. Simultaneous execution is only for demonstration of technique.) This carries through to later forms, where almost all techniques are demonstrated to both sides. (The few which aren't done on both sides could be.)

{{BookCat}}</text>
      <sha1>1x1lo9onn8jf8oeykjytxb4gogv8rks</sha1>
    </revision>
  </page>
  <page>
    <title>Scheme Programming/Using a Scheme interpreter</title>
    <ns>0</ns>
    <id>180264</id>
    <revision>
      <id>4657106</id>
      <parentid>3771526</parentid>
      <timestamp>2026-08-10T21:41:46Z</timestamp>
      <contributor>
        <username>~2026-44027-61</username>
        <id>3620571</id>
      </contributor>
      <comment>/* REPL bookmarklet */ direct link to Boomarklet</comment>
      <origin>4657106</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1717" sha1="ctcu6dri2fiu67gy6kcg9f5eag3v4qc" xml:space="preserve">{{attention}}
{{Navigation|Book=Scheme Programming|previous=What defines Scheme?|current=Using a Scheme Interpreter|next=A taste of Scheme}}

On most Unix machines, 'scm' can be installed. This is a Scheme interpreter which adheres to R5RS very well. 

To invoke the interpreter, simply type 'scm' at the command line. It is common to write your programs into a text file using Vim or emacs, and then load them in using the 'load command':
&lt;syntaxhighlight lang=&quot;Scheme&quot;&gt;
$ scm
&gt; (load &quot;myFile.scm&quot;)
#&lt;unspecified&gt;
&gt;
&lt;/syntaxhighlight&gt;

Windows users have a number of options for getting a standards-conforming Scheme implementation. Both PLT Scheme/Racket and MIT/GNU Scheme will work. (However, keep in mind that Racket implements its own version of the language, with considerable changes in syntax). 

There are a great many Scheme systems available for use, and, unfortunately, they can all behave quite differently. Portability for Scheme programs written using non-standard features are rare, so often the correctness of one's code will vary depending on the compiler or interpreter used. For this reason, when maximum portability is desired, it is wise to write all code in R5RS, as this is the most widely implemented standard. (R6RS has elicited controversy from some).

== REPL bookmarklet ==

[[File:WikiBooks Scheme REPL.png|thumb|300|The look of the REPL on this page]]

While reading this book you can use bookmarklet that will create Scheme REPL directly on this wiki book, the link to bookmarklet can be found at [https://lips.js.org/#bookmark LIPS Scheme website]. You will need to run this bookmark on each page you visit, because it will be gone, after you navigate to different page.

{{BookCat}}</text>
      <sha1>ctcu6dri2fiu67gy6kcg9f5eag3v4qc</sha1>
    </revision>
    <revision>
      <id>4657107</id>
      <parentid>4657106</parentid>
      <timestamp>2026-08-10T22:04:48Z</timestamp>
      <contributor>
        <username>Jcubic</username>
        <id>406082</id>
      </contributor>
      <comment>rewriting</comment>
      <origin>4657107</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2084" sha1="lbwbqe7buccr8lo3yn491lh44cmu8fy" xml:space="preserve">{{attention}}
{{Navigation|Book=Scheme Programming|previous=What defines Scheme?|current=Using a Scheme Interpreter|next=A taste of Scheme}}

The most popular Scheme interpreter are:

* [[:w:GNU_Guile|Guile]]
* [[:w:Kawa (Scheme implementation)|Kawa]]
* [[:w:Gambit (Scheme implementation)|Gambit]]
* [[:w:Chicken (Scheme implementation)|Chicken]]
* [[:w:MIT/GNU Scheme|MIT/GNU Scheme]]

You can install any of them on your system and run from the [[:w:Terminal emulator|terminal]] in so called REPL ([[:w:Read–eval–print loop|read-eval-print loop]]).

There are a great many Scheme systems available, but portability for Scheme programs written using non-standard features are rare, so often the correctness of one's code will vary depending on the compiler or interpreter used. For this reason, when maximum portability is desired, it is wise to write all code in R7RS, as this is the most widely implemented standard.

Yet another popular language compatible with Scheme is [[:w:Racket (programming language)|Racket]]. It's Scheme like system for experimenting with programming langauges, it has [https://pkgs.racket-lang.org/package/r7rs R7RS compatible language].

You can find more information about Scheme compatibllity and quirks of different Scheme interpreters on [https://docs.scheme.org/surveys/ Scheme offical website]. Offical website also has links to [https://standards.scheme.org/ R&lt;sup&gt;n&lt;/sup&gt;RS specifications].

You can find a fully working web based interpreter of Gambit Scheme on [https://try.scheme.org/ try.scheme.org] (desktop only).

== REPL bookmarklet ==

[[File:WikiBooks Scheme REPL.png|thumb|300|The look of the REPL on this page]]

While reading this book you can use bookmarklet that will create Scheme REPL directly on this wiki book, the link to bookmarklet can be found at [https://lips.js.org/#bookmark LIPS Scheme website]. You will need to run this bookmark on each page you visit, because it will be gone, after you navigate to different page. (NOTE: the LIPS Scheme intepreter doesn't support tail calles and continuations). 

{{BookCat}}</text>
      <sha1>lbwbqe7buccr8lo3yn491lh44cmu8fy</sha1>
    </revision>
    <revision>
      <id>4657108</id>
      <parentid>4657107</parentid>
      <timestamp>2026-08-10T22:07:15Z</timestamp>
      <contributor>
        <username>Jcubic</username>
        <id>406082</id>
      </contributor>
      <comment>Remove Racket paragraph</comment>
      <origin>4657108</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1928" sha1="swo2w3lf7vn38qcs02k32lusnb9sgpa" xml:space="preserve">{{attention}}
{{Navigation|Book=Scheme Programming|previous=What defines Scheme?|current=Using a Scheme Interpreter|next=A taste of Scheme}}

The most popular Scheme interpreter are:

* [[:w:GNU_Guile|Guile]]
* [[:w:Kawa (Scheme implementation)|Kawa]]
* [[:w:Gambit (Scheme implementation)|Gambit]]
* [[:w:Chicken (Scheme implementation)|Chicken]]
* [[:w:MIT/GNU Scheme|MIT/GNU Scheme]]
* [[:w:Racket (programming language)|Racket]] (Scheme like system with compatibility layer)

You can install any of them on your system and run from the [[:w:Terminal emulator|terminal]] in so called REPL ([[:w:Read–eval–print loop|read-eval-print loop]]).

There are a great many Scheme systems available, but portability for Scheme programs written using non-standard features are rare, so often the correctness of one's code will vary depending on the compiler or interpreter used. For this reason, when maximum portability is desired, it is wise to write all code in R7RS, as this is the most widely implemented standard.

You can find more information about Scheme compatibllity and quirks of different Scheme interpreters on [https://docs.scheme.org/surveys/ Scheme offical website]. Offical website also has links to [https://standards.scheme.org/ R&lt;sup&gt;n&lt;/sup&gt;RS specifications].

You can find a fully working web based interpreter of Gambit Scheme on [https://try.scheme.org/ try.scheme.org] (desktop only).

== REPL bookmarklet ==

[[File:WikiBooks Scheme REPL.png|thumb|300|The look of the REPL on this page]]

While reading this book you can use bookmarklet that will create Scheme REPL directly on this wiki book, the link to bookmarklet can be found at [https://lips.js.org/#bookmark LIPS Scheme website]. You will need to run this bookmark on each page you visit, because it will be gone, after you navigate to different page. (NOTE: the LIPS Scheme intepreter doesn't support tail calles and continuations). 

{{BookCat}}</text>
      <sha1>swo2w3lf7vn38qcs02k32lusnb9sgpa</sha1>
    </revision>
    <revision>
      <id>4657109</id>
      <parentid>4657108</parentid>
      <timestamp>2026-08-10T22:09:29Z</timestamp>
      <contributor>
        <username>Jcubic</username>
        <id>406082</id>
      </contributor>
      <origin>4657109</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1964" sha1="6odmz68udjqar047icnyuv6h5pipa25" xml:space="preserve">{{attention}}
{{Navigation|Book=Scheme Programming|previous=What defines Scheme?|current=Using a Scheme Interpreter|next=A taste of Scheme}}

The most popular Scheme interpreter are:

* [[:w:GNU_Guile|Guile]]
* [[:w:Kawa (Scheme implementation)|Kawa]]
* [[:w:Gambit (Scheme implementation)|Gambit]]
* [[:w:Chicken (Scheme implementation)|Chicken]]
* [[:w:MIT/GNU Scheme|MIT/GNU Scheme]]
* [[:w:Racket (programming language)|Racket]] (Scheme like system with compatibility layer)

You can install any of them on your system and run from the [[:w:Terminal emulator|terminal]] in so called REPL ([[:w:Read–eval–print loop|read-eval-print loop]]).

There are a great many Scheme systems available, but portability for Scheme programs written using non-standard features are rare, so often the correctness of one's code will vary depending on the compiler or interpreter used. For this reason, when maximum portability is desired, it is wise to write all code in R7RS, as this is the most widely implemented standard.

You can find more information about Scheme compatibllity and quirks of different Scheme interpreters on [https://docs.scheme.org/surveys/ Scheme offical website]. Offical website also has links to [https://standards.scheme.org/ R&lt;sup&gt;n&lt;/sup&gt;RS specifications].

You can find a fully working web based interpreter of Gambit Scheme on [https://try.scheme.org/ try.scheme.org] (desktop only).

== REPL bookmarklet ==

[[File:WikiBooks Scheme REPL.png|thumb|300|The look of the REPL on this page]]

While reading this book you can use bookmarklet that will create Scheme REPL directly on this wiki book, the link to bookmarklet can be found at [https://lips.js.org/#bookmark LIPS Scheme website]. You will need to run this bookmark on each page you visit, because it will be gone, after you navigate to different page. (NOTE: the LIPS Scheme intepreter doesn't support tail calls and [[Scheme Programming/Continuations|continuations]]). 

{{BookCat}}</text>
      <sha1>6odmz68udjqar047icnyuv6h5pipa25</sha1>
    </revision>
  </page>
  <page>
    <title>Aros/Platforms/AROS USB support</title>
    <ns>0</ns>
    <id>202147</id>
    <revision>
      <id>4657087</id>
      <parentid>4657018</parentid>
      <timestamp>2026-08-10T18:59:06Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657087</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="671922" sha1="51psucdq02yjpkpgluut1c7k0c02jrj" xml:space="preserve">
{{ArosNav}}


==Host Adapter Protocol USB1 OHCI UHCI USB2 EHCI USB3.0 USB3.1 xHCI ==

Please let us know any mistakes or any information to be added, use Prefs/Trident to confirm Vendor and Product IDs 
Please chat at [https://www.arosworld.org/index.php AROS World]

*1996 USB1.0
*1998 USB1.1
*2000 USB2.0
*2008 USB3.0
*2013 USB3.1
*2017 USB3.2

[https://github.com/aros-development-team/AROS/tree/master/rom/usb AROS has these USB transfers] 

*Control     - 
*Bulk        - Midi 1.0 ( 'send my data when you can' )
*Interrupt   - Midi 2.0
*Isochronous - USBAudio, Webcams, etc (wip) 

Isochronous is the starting point of modern types of multimedia creativity. IsoChronous isoc code is already in place in poseidon.library and '''scheduled''' transfers are queued to be later rerouted in the host driver code (needs to be written for each host protocol e.g. OCHI, UCHI, EHCI and [https://cdrdv2-public.intel.com/625472/625472_xHCI_Rev1_2b.pdf#:~:text=Page%203.%20Document%20Number:%20625472%2C%20Revision:%201.2b.%203. XHCI rev1.2], [https://www.intel.com/content/www/us/en/content-details/868296/extensible-host-controller-interface-for-universal-serial-bus-xhci-requirements-specification-r2-0.html rev2], etc). There seems to be 2 types of isoc transfers, one is just the normal isoc transfer and the other is realtime implementation of isoc transfer. 

For isoc transfer there needs to be a scheduler that makes sure no isoc transfers are dropped (in or out) and that they happen at the right time. It all gets difficult as the device making use of the isoc transfer may be at any point on the device tree. One needs to calculate the USB bandwidth for the packet based periodic transfers that are initiated by the host which have fixed but guaranteed bandwidth. Host controllers guarantee this bandwidth by planning a schedule of transfers ahead of time to ensure there is enough time reserved on the bus.

[https://www.intel.co.uk/content/www/uk/en/products/docs/io/universal-serial-bus/ehci-specification.html EHCI] [https://www.thegoodpenguin.co.uk/blog/understanding-why-usb-isochronous-bandwidth-errors-occur/ bus-bandwidth] vs payload-bandwidth and the algorithm of the EHCI scheduler. 
The bandwidth of the endpoint in terms of payload data (stuff we put in a packet) and the protocol overhead, signalling imposed bit stuffing, host delays etc. 

Poseidon controls the driver and device tree and it provides an API to communicate with the USB devices. Poseidon really doesn't care much about what sort of transfer pipe is opened or used, it only provides the means to do so and forwards the iorequests to the correct driver. Poseidon code is the higher level code for USB communication and drivers are of course the lower level one.


[[File:Psd.svg|220px|right]]


; Best Hardware - NEC Chipset (OHCI + EHCI), Intel Chipset (UHCI + EHCI), 
; Early support - [https://github.com/aros-development-team/AROS/commit/03c5252d962941a56c816a9f2315134362089349 XHCI USB3.0, USB3.1 &amp; gen 2 Type-A Type-B Type-C] 
; Next Best Set - General OHCI, SIS (OHCI + EHCI), 
; Buggy Chipset - [ Early AMD OHCI], ALi OHCI, VIA UHCI, Nvidia OHCI &amp; EHCI, 


=== USB1.1 ===
OHCI USB 1.1 - USB-IF sanctioned standard but hardware physical form removed with USB2.0 and replaced with virtual emulation of USB1 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;10%&quot; |Boot from USB
! width=&quot;10%&quot; |Detect USB device 
! width=&quot;10%&quot; |USB device works 
! width=&quot;30%&quot; |Opinion
|-
| ALi Agere M5273 A1 M5237 Lucent USS-312 
| 
| 
| 
| &lt;!--Boots--&gt;{{Maybe}}
| &lt;!--Detects--&gt;{{Yes}}
| &lt;!--Works--&gt;{{Maybe|}}
| StarTech PCI425USB, CompUSA Iogear GIC220U-b, Nvidia 220 mobo, USBA2041P, ALi SU2A-PS, 
|-
| AMD 756 Chipset (onboard motherboard) 
| 0x1022 
| 0x740c 
| 0x06
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{No}}
| &lt;!--Works--&gt;{{Maybe|}}
| no [http://aros-exec.org/modules/newbb/viewtopic.php?post_id=31308#forumpost31308 usb devices detected] Geode GX1, 
|-
| CMD DU-A2 Silicon Image 0670 (pci AMD chipset)
| 0x1095
| 0x0670
| 0x06
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{No}}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
| Silicon Image 0673 (pci AMD chipset)
| 0x1095
| 0x0673
| 0x06
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{No}}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
| Nvidia Nforce2 USB
| 0x10de 
| 
| 
| &lt;!--Boots--&gt;{{Maybe|Bios options vary but does with Plop Boot}}
| &lt;!--Detects--&gt;{{Yes}}
| &lt;!--Works--&gt;{{Maybe|}}
| Tested with 20th Aug 2012 improvement 
|-
| NEC µPD720100AGM 
| 0x1033
| 0x0035
| 0x 
| &lt;!--Boots--&gt;{{Unk}}
| &lt;!--Detects--&gt;{{Unk}}
| &lt;!--Works--&gt;{{Maybe|}}
| untested - Amiga Spider card with possible bottleneck issues at higher speeds 
|-
| NEC µPD720101AGM 720101GJ
| 0x1033
| 0x0035
| 0x43
| &lt;!--Boots--&gt;{{Yes}}
| &lt;!--Detects--&gt;{{Yes}}
| &lt;!--Works--&gt;{{Maybe|}}
| Mac mini, Belkin F5U219vea (2+1 ports), Belkin F5U220vea1 (4+1 ports), Adaptec 3100LP, BAFO BF-460, GWC UC-160, IOGear GIC250U, Keyspan U2PCI-5, O'toLink U2-C2B U2-C2A U2-P20N U2-P50, Ratoc PCIU5, USBWholesale UII-PCIP 
|-
| NEC µPD720102
| 0x1033
| 0x00
| 0x 
| &lt;!--Boots--&gt;{{Unk|untested }}
| &lt;!--Detects--&gt;{{Unk|untested }}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
| Opti 82C861 2-port 
| 0x1045
| 0xc861
| 
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{No}}
| &lt;!--Works--&gt;{{Maybe|}}
| no USB devices detected - Belkin F5U005, 
|-
| SIS 7001 OCHI 
| 0x1039
| 0x7001
| 0x0f
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Yes}}
| &lt;!--Works--&gt;{{Maybe|}}
| 20th Aug 2012 - not booting stalls on GRUB word with Plop Boot 
|-
|}


UHCI USB 1.1 - Intel standard but since 2009 no hardware support as USB2 introduced virtual emulation of USB1 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;10%&quot; |Boot from USB
! width=&quot;10%&quot; |Detect USB device
! width=&quot;10%&quot; |USB device works 
! width=&quot;30%&quot; |Opinion
|-
| Intel 
| 0x8086 
| 0x
| 0x01 
| &lt;!--Boots--&gt;{{No|not in bios use AROS floppy disc boot}}
| &lt;!--Detects--&gt;{{Maybe|}}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
| Intel 82371AB EB MB PIIX4 
| 0x8086 
| 0x7112
| 0x01 
| &lt;!--Boots--&gt;{{No|none in bios use other booting options}}
| &lt;!--Detects--&gt;{{Maybe|Detects most devices}}
| &lt;!--Works--&gt;{{Maybe|most devices but not RTL8187b WG111v3 blue led not on and does not work}}
|  
|-
| Intel 82801DB/DBL/DBM (onboard i830 mbd)
| 0x8086 
| 0x24c4 
| 0x01 
| &lt;!--Boots--&gt;{{Yes|but not from bios but floppy options}}
| &lt;!--Detects--&gt;{{Yes|}}
| &lt;!--Works--&gt;{{Yes|}}
| RTL8187b WG111v3 blue led on and although device has software failure and recoverable error IT STILL WORKS. Fresh start sometimes needs Network Prefs Saved to work. 
|-
| VIA MVP4 (onboard mbd)
| 0x1106
| 0x30
| 0x40 
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Maybe|most devices}}
| &lt;!--Works--&gt;{{Maybe|most devices but not wireless options}}
| RTL8187b WG111v3 detected but blue led not on and does not work 
|-
| VIA VT82xx (onboard mbd)
| 0x1106
| 0x3038
| 0x40 
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Maybe|most devices}}
| &lt;!--Works--&gt;{{Maybe|most devices but not wireless usb}}
| RTL8187b WG111v3 blue led on but does not work 
|-
| VIA VT6202 (VIA VT83C572)
| 0x1106
| 0x3038
| 
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Maybe|}} 
| &lt;!--Works--&gt;{{Maybe|}}
| A-Best USB-200, Cables N Mor USBPCI, CompUSA, D-Link DSB500, Digital/Research DRUSBCARD, Kouwell IOFlex 580, StarMount USB VIA, 
|-
| VIA VT6112 
| 
| 
| 
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Maybe|}}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
| VIA VT6212 (pci card)
| 0x1106
| 0x3038
| 0x61
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Maybe|}}
| &lt;!--Works--&gt;{{Maybe|}}
| 2011 seems to have issues with other identical via based USB controller(s) present 
|-
| VIA VT6214L 
| 
| 
| 
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Maybe|}}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
|}


=== USB 2.0 EHCI ===
The USB-IF insisted on only one implementation of EHCI but it creates 4 virtual hcd to cover USB1.1 support. The virtual HCD on Intel and VIA EHCI controllers are UHCI. All other vendors use virtual OHCI controllers. Hardware EHCI USB2.0 ended in most chipsets in 2014/5 and is now virtual through most newer USB3.0 chipsets 

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;10%&quot; |Boot from USB
! width=&quot;10%&quot; |Detect USB device
! width=&quot;10%&quot; |USB device works 
! width=&quot;30%&quot; |Opinion
|-
| ALi Agere M5273 A1 Lucent USS-344 
| 
| 
| 
| &lt;!--Boots--&gt;
| &lt;!--Detects--&gt;
| &lt;!--Works--&gt;{{Maybe|}}
| {{N/A|untested}} belkin F5U006, 
|-
| Nvidia Nforce2 USB
| 
| 
| 
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Yes}}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
| Intel 82801DB/DBM (onboard mbd)
| 0x8086 
| 0x24cd 
| 0x01 
| &lt;!--Boots--&gt;{{Yes}}
| &lt;!--Detects--&gt;{{Yes}}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
| NEC µPD720100AGM 
| 0x1033
| 0x00E0
| 0x 
| &lt;!--Boots--&gt;
| &lt;!--Detects--&gt;
| &lt;!--Works--&gt;{{Maybe|}}
| {{N/A|untested - Amiga Spider card}}
|-
| NEC 72101 GJ
| 0x1033 
| 0x00e0 
| 0x04
| &lt;!--Boots--&gt;{{Yes}}
| &lt;!--Detects--&gt;{{Yes}}
| &lt;!--Works--&gt;{{Maybe|}}
| Belkin F5U219 VEA1 (pci), 
|-
| SIS ECHI 
| 0x1039
| 0x7002
| 0x00
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Maybe|issues about which port is used if it works at all}}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
| VIA VT6202 
| 0x1106
| 0x3104
| 
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Yes}}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
| VIA VT6212 (pci card)
| 0x1106
| 0x3104
| 0x62
| &lt;!--Boots--&gt;{{No}}
| &lt;!--Detects--&gt;{{Yes|detects}}
| &lt;!--Works--&gt;{{Maybe|}}
| 
|-
|}


=== USB 3.x SuperSpeed SS (Speed 5Gbit/s 3.1 gen 1) aka xHCI eXtensible ===

USB Attached SCSI (UAS or UASP) is a protocol used for high-speed data transfer between computers and external storage devices like SSDs, HDDs, and some flash drives. It provides up to 70% faster read/write speeds than traditional Bulk-Only Transport (BOT) by allowing multiple commands to run in parallel, rather than waiting in a queue

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;10%&quot; |Boot from USB
! width=&quot;10%&quot; |Detect USB device
! width=&quot;10%&quot; |USB device works 
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;AMD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;AMD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;AMD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Fresco Logic FL1000 FL 1000 
| &lt;!--Vendor ID--&gt;0x1B73
| &lt;!--Product ID--&gt;0x1000 
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;link power management (LPM, USB 3.0 power saving) cannot be disabled so random connection issues  
|-
| &lt;!--Description--&gt;Fresco Logic FL1009-200 FL 1009 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x1009 
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;Orico PFU3-2P
|-
| &lt;!--Description--&gt;Fresco Logic FL1100-100 FL 1100SX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x1100 
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;LPM cannot be disabled so issues with disconnecting WD drives etc - CalDigit, ORICO PFU3-2P, FASTA-6GU3 Pro, inatech KTU3FR-2P 2 port USB 3.0,  and Inateck KT4004 (KTU3FR-4PA rev B2) for storage and hubs, etc 
|-
| &lt;!--Description--&gt;Fresco Logic FL1400 FL 1400 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x1400 
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Fresco Logic 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;NEC Renesas xHCI µPD720200 uPD720200a chip
| &lt;!--Vendor ID--&gt;0x1d6b
| &lt;!--Product ID--&gt;0x0194
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{Maybe|no USB3 but seems to works like USB2}}
| &lt;!--Opinion--&gt;recognized but not supported for USB3 but works like USB2 - ORICO PRU3-4P 4 Port USB, early Dell Wyse zx0 thin client,  
|-
| &lt;!--Description--&gt;NEC Renesas xHCI µPD720201 uPD720201 chip
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x114 0x0115 
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;recognized but not supported 
|-
| &lt;!--Description--&gt;NEC Renesas xHCI µPD720202 uPD720202 chip
| &lt;!--Vendor ID--&gt;0x1912 
| &lt;!--Product ID--&gt;0x0015
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;recognized but not supported 
|-
| &lt;!--Description--&gt;[http://www.ti.com/product/tusb7340 TI] tusb7340 TUSB732 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x8241
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;recognized but not supported Koutech IO-PEU436 but only one with open docs 
|-
| &lt;!--Description--&gt;Intel xHCI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;recognized but not supported - integrated since Ivybridge 
|-
| &lt;!--Description--&gt;Intel xHCI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Marvell 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Via Labs VL800 xHCI 0.96 support in VL800, VIA VL811 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x3432 0x3438 0x3515 and 0x9201
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{Maybe|}} 2.0 backwards support 
| &lt;!--Opinion--&gt;Anker 68UPPCIE-2S20PU 2 port, Plugable 4-Port, GA-z77x-ud5h rev. 1.1 mobo, 
|-
| &lt;!--Description--&gt;Via Labs VL811+ 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Via Labs VL812 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;xHCI 1.0 support in VL805 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
|}


USB 3.1 (power up to 100W and data 10Gbit/s USB 3.2 gen 2 - USB-A Full size plug - USB-B micro USB size - USB-C reversible) 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;10%&quot; |Boot from USB
! width=&quot;10%&quot; |Detect USB device
! width=&quot;10%&quot; |USB device works 
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;Asmedia ASM1142 
| &lt;!--Vendor ID--&gt;0x1B21 
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{No| }}
| &lt;!--Opinion--&gt;Connector: USB Type C and  USB Type A x 1 - Ugreen USB C PCI Card 2 Port USB 3.1 Type C 
|-
| &lt;!--Description--&gt;Marvell 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;AMD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Intel 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Intel xHCI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;[ Intel] Revision 1.8 1.9 Updated  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;VLI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{N/A|}}
| &lt;!--Opinion--&gt;AUKEY 4 Ports USB C , 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{N/A|}}
| &lt;!--Opinion--&gt;Startech - PEXUSB312C - 2-port Usb 3.1 10Gbit/s
|-
|}

USB 3.2 (power up to 100W and data 20Gbit/s gen 2x2 - USB-A Full size plug - USB-B micro USB size - USB-C reversible) 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;10%&quot; |Boot from USB
! width=&quot;10%&quot; |Detect USB device
! width=&quot;10%&quot; |USB device works 
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;Marvell 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;AMD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Intel 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Intel xHCI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;[ Intel] Revision 2.6 Update  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{unk| }}
| &lt;!--Detects--&gt;{{unk|}}
| &lt;!--Works--&gt;{{unk|}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;VLI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{N/A|}}
| &lt;!--Opinion--&gt;
|-
|}

=== USB 4 (40Gbps thunderbolt, pcie 3.0 tunnelling, ) ===
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;10%&quot; |Boot from USB
! width=&quot;10%&quot; |Detect USB device
! width=&quot;10%&quot; |USB device works 
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;Marvell 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{No| }}
| 
|-
| &lt;!--Description--&gt;AMD Ryzen7 6800U 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{No| }}
| 
|-
| &lt;!--Description--&gt;Intel Goshen Ridge JHL8440 Controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{No| }}
| 
|-
| &lt;!--Description--&gt;VLI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Boots--&gt;{{N/A}}
| &lt;!--Detects--&gt;{{N/A|}}
| &lt;!--Works--&gt;{{N/A|}}
|  
|-
|}


== hid.class (Human Interface Device) ==

=== Keyboard ===

 Some multi-finger touchpad support works but not on all touchpads  

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;8BitDo Retro N C64 edition Keyboard, the super button accessory and optional N30 mouse
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 87 keys Kailh white}}
|-
| &lt;!--Description--&gt;8bitdo 108 Retro Mechanical Keyboard (white kailh) and two superbuttons (green) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Apple Pro Keyboard
| 0x05ac
| 0x0205 
| 0x0122
| {{yes|works (its two hub ports) but mouse scroll wheel issues}}
|-
| Apple Pro Keyboard
| 0x05AC
| 0x020B 
| 
| {{yes|works (two onboard ports also)}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Aigo K68 60% red switches, A68 A87 wireless 2G 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;[http://amigakit.leamancomputing.com/catalog/product_info.php?cPath=49&amp;products_id=973 AmigaOne Keyboard]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes|works}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Akko TAC87 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 80% TKL }}
|-
| &lt;!--Description--&gt;Akko MonsGeek FUN60 PRO&amp;MAX HE
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 60% hall effect }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Akko 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2025 hall effect, good but expensive and software poor}}
|-
| &lt;!--Description--&gt;Akko 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;ATTACK SHARK X98 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 98% maybe silent linear feel with Two-color PBT keycap}}
|-
| &lt;!--Description--&gt;ATTACK SHARK X68HE 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 hall effect }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Azio Cascade 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Chilkey ND75 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024  good 75% expensive}}
|-
| &lt;!--Description--&gt;Chilkey ND104 (Wuque Studios) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 premium clicky (WS Blue) or silent (WS White) key options with Ansi and ISO formats also numpad and calculator, aluminum machined, tri mode, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2026 untested magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Corsair K65 Mech MX no numeric keypad 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Corsair CH-9000045 K70 Blue MX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Corsair K90 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Corsair K95 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Corsair K
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Cherry G80 G80-3000L[x]C[yy]-[z] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Cooler Master CM Storm Quickfire Rapid 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Corsair K100 Air 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2025 okay low profile but expensive 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion
|-
| &lt;!--Description--&gt;Dell SK-8135 Dell USB Keyboard for Internet and Multimedia rev H for Dimension 4500, Dimension 8250, OptiPlex GX260n, OptiPlex GX60n, Precision 350 (R42232) 
| &lt;!--Vendor ID--&gt;0x413C
| &lt;!--Product ID--&gt;0x2010 
| &lt;!--Revision--&gt;0200 
| &lt;!--Opinion--&gt;{{Yes| usb1.1 keyboard hub 0x413C 0x1003 works as well - multimedia keys not mapped }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Deepcool KG722
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 65% }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Ducky Channel Zero DK2108 Mech Mechanical Cherry MX Red 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Ducky Shine 3 Brown or Blue (DK9087) MX keys 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Das Keyboard Model S Ultimate 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Epomaker Cidoo V75 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2023 untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;epomaker rt100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 plastic build and no screws, numpad with small 0, mostly quiet seasalt switches, gimmick usb-c 1in screen}}
|-
| &lt;!--Description--&gt;EPOMAKER TH99  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }} USB-C full numpad keyboard 
|-
| &lt;!--Description--&gt;eopmaker P75 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| expensive but good}}
|-
| &lt;!--Description--&gt;eopmaker p87 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| expensive but good}}
|-
| &lt;!--Description--&gt;epomaker x Leobog Hi75
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024  }}
|-
| &lt;!--Description--&gt;epomaker x Feker Galaxy80
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024  }}
|-
| &lt;!--Description--&gt;epomaker x Galaxy100 gmk/via 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 good 96% }}
|-
| &lt;!--Description--&gt;epomaker Aula F75 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 budget version good 75% choice of 4 leobog switches}}
|-
| &lt;!--Description--&gt;eopmaker Tide75 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 good 75% and not too expensive}}
|-
| &lt;!--Description--&gt;Epomaker Ajazz AK820 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 }}
|-
| &lt;!--Description--&gt;Epomaker Ajazz AK35I V3 MAX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 104 keys - two models: wired and tri-mode connection - }}
|-
| &lt;!--Description--&gt;epomaker Aula F108 PRO 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 pricy but okay 100% but only leobog graywood switches but hotswap available afterwards}}
|-
| &lt;!--Description--&gt;eopmaker Ajazz AK980 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 97 keys }}
|-
| &lt;!--Description--&gt;Epomaker G87 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 }}
|-
| &lt;!--Description--&gt;Epomaker RT82 RT85
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 }}
|-
| &lt;!--Description--&gt;Epomaker RT100 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 96% }}
|-
| &lt;!--Description--&gt;epomaker x Galaxy100 lite 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 good 96% }}
|-
| &lt;!--Description--&gt;Epomaker 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Filco Ninja Majestouch-2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Focus FK-760 Wireless Keyboard &amp; Trackball
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{yes|works}} but quality build issues raised 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;GMMK Tenkeyless 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested  default Gateron Brown switches for Kailh Box Jades default Gateron Brown switches for Kailh Box Jades}}
|-
| &lt;!--Description--&gt;GK61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2023 untested }}
|-
| &lt;!--Description--&gt;GMK67 GMK87 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested budget good option}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Hengchangtong HCT Limeme gk103s Entry Keyboard
| &lt;!--Vendor ID--&gt;0xC0F4
| &lt;!--Product ID--&gt;0x0009
| &lt;!--Revision--&gt;0100
| &lt;!--Opinion--&gt;{{yes|half Keyboard left side only}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Hexgears M2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2024 untested hotswap kaihl green switches}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Hexgears 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Iqunix mq80
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2025 good 75% low profile keys
|-
| &lt;!--Description--&gt;Iqunix Magi65 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested good 65% low profile keys }}
|-
| &lt;!--Description--&gt;iqunix ez60 ez80 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2025 untested specific hall effect switches - actuation point, rapid trigger, etc }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Jomaa YiChip Wireless 50% key with touchpad 
| &lt;!--Vendor ID--&gt;0x3151 
| &lt;!--Product ID--&gt;0x3000
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|dongle detected, keys and pad not working - 2 AAA NM}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Keychron q0
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2022 untested numpad only}} 
|-
| &lt;!--Description--&gt;Keychron q1 v1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2022 untested okay}} 
|-
| &lt;!--Description--&gt;Keychron Q6 Max 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2023 untested 75% with numeric numpad, barebones so choose switches and keycaps to suit }}
|-
| &lt;!--Description--&gt;Keychron q1 MAX V1 MAX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2023 untested }} 
|-
| &lt;!--Description--&gt;Keychron Lemokey P1 QMK 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested best option to customise switches and keycaps}}
|-
| &lt;!--Description--&gt;Keychron LemoKey X1 X3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2024 untested keycap swap only not switches}}
|-
| &lt;!--Description--&gt;Keychron K2HE
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested okay}} wireless hall effect analogue on all keys 
|-
| &lt;!--Description--&gt;Keychron K4HE 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2025 untested hall effect but software }}
|-
| &lt;!--Description--&gt;Keychron K5 K17 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 untested okay low profile but }}
|-
| &lt;!--Description--&gt;Keychron Q5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 }}
|-
| &lt;!--Description--&gt;Keychron K10 HE 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 }}
|-
| &lt;!--Description--&gt;Kiiboom Breeze 75 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2025 good 75% }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2025 }}
|-
| &lt;!--Description--&gt;Meletrix Boog 75 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2024 magnetic hall effect, good but expensive and software poor}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2025 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2025 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2025 }}
|-
| &lt;!--Description--&gt;Melgeek O2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2025 low profile 75% but not repairable}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2025 }}
|-
| &lt;!--Description--&gt;MOSART 2.4G Wireless 60% Keyboard Trackball 
| &lt;!--Vendor ID--&gt;0x062a
| &lt;!--Product ID--&gt;0x4105
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Yes|dongle recognised HID, keys worked, roller worked, scroll wheel works and shoulders works but buttons around left, top and right hand side (RHS) do not work and plastic and 2 AA MN1500}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Mucai SiGma Micro MKA610 
| &lt;!--Vendor ID--&gt;0x1c4f
| &lt;!--Product ID--&gt;0x0084
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| unknown red keys - rgb backlighting - }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion
|-
| &lt;!--Description--&gt;[http://hjldemo.clsc.cn/ Guangzhou Zhentian Electronics Ltd] Perixx Periboard 505 Plus with Trackball 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Yes|okay dome keyboard - poor trackball}}
|-
| &lt;!--Description--&gt;Guangzhou Zhentian Electronics Co., Ltd Perixx Periboard 706 Plus with Trackball Wireless 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Yes|generally okay dome with good sized keys but piano black surround fingerprint magnet, occasional brief trackball freezes after no use, takes some time to get used to the trackball size}} 
|-
| &lt;!--Description--&gt;Perixx Periboard-716 Wireless (Chicony)
| &lt;!--Vendor ID--&gt;04f2:1013
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Yes|okay dome keyboard and trackpad}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Description--&gt;Perixx Periboard-
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Unk|okay keyboard}}
|-
| &lt;!--Description--&gt;Perixx Periboard-
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Unk|okay keyboard}}
|-
| &lt;!--Description--&gt;Lenovo SK-8825 41A5327 SIL12-W07 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;works manufactured for 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Lite-On USB NetVista Full Width Keyboard 
| &lt;!--Vendor ID--&gt;0x04b3
| &lt;!--Product ID--&gt;0x3025
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;works 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Logitech K320 Wireless Keyboard 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|The Logitech USB Unifying, Bolt, Lightspeed, or Nano receiver pairing}}
|-
| &lt;!--Description--&gt;Logitech K340 Wireless Keyboard 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|The Logitech Unifying Receiver pairing}}
|-
| &lt;!--Description--&gt;Logitech K400
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Unk|okay keyboard}}
|-
| &lt;!--Description--&gt; [http://www.logitech.com/en-us/product/wireless-touch-keyboard-k400r Logitech Wireless Touch Keyboard k400]
| &lt;!--Vendor ID--&gt; 0x046D
| &lt;!--Product ID--&gt; 0xC52B
| &lt;!--Revision--&gt; 1201
| &lt;!--Opinion--&gt; {{yes|All (including multimedia) keys work. Some keys requires remapping with Trident. Touchpad works and acts as normal mouse. Presents itself in Trident as USB Receiver from Logitech with 3 HID bindings}}
|-
| &lt;!--Description--&gt;Logitech K400 Plus K400+ 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Unk|okay keyboard}}
|-
| &lt;!--Description--&gt;Logitech K600 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Unk|okay keyboard}}
|-
| &lt;!--Description--&gt;Logitech TK820 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Unk|okay keyboard}}
|-
| &lt;!--Description--&gt;Logitech TK830 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Unk|okay keyboard}}
|-
| &lt;!--Description--&gt;Logitech G915 TKL
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Unk|okay keyboard TKL means no number pad}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Lofree Lite84 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 }}
|-
| &lt;!--Description--&gt;Lofree Flow Lite100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 silent switches and low profile keys}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion
|-
| &lt;!--Description--&gt;MACHENIKE K500 Wired 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2024 94 keys untested Hot Swappable 94 Keys 90% Layout }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;MechLands Vibe99 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2024 100 keys untested Gasket-mounted Wired/Bluetooth/2.4GHz Wireless Mechanical Keyboard}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Microsoft Comfortable Curve 2000
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no| recognized but not supported}}
|-
| &lt;!--Description--&gt;Microsoft Natural Ergonomic Keyboard 4000
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|recognized but not supported}}
|-
| &lt;!--Description--&gt;Microsoft Wireless Media Desktop 1000 (1356)
| &lt;!--Vendor ID--&gt;0x045e
| &lt;!--Product ID--&gt;0x00f9 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{maybe|working but not mouse part}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Niz Micro84 Duo82 X87 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 electro capacitive }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;nuphy gem80 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| expensive but good}}
|-
| &lt;!--Description--&gt;nuphy kick 75 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 low profile 75% }}
|-
| &lt;!--Description--&gt;nuphy Air75 V3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025  75% }}
|-
| &lt;!--Description--&gt;nuphy node 100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 96% layout, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Qpad MK-50 MK-80 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Qpad MK-90 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Razer Chroma 
| &lt;!--Vendor ID--&gt;0x1532
| &lt;!--Product ID--&gt;0203
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;[https://openrazer.github.io/ Razer] Lycosa 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Razer Blackwidow 2013 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Razr Blackwidow Ultimate 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Razer Cynosa Lite V2 
| &lt;!--Vendor ID--&gt;1532
| &lt;!--Product ID--&gt;0x023f
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Razer DeathStalker 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Razer HuntsMan 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Razer Ornata 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Razer Orbweaver Chroma Keypad 
| &lt;!--Vendor ID--&gt;0x1532
| &lt;!--Product ID--&gt;0207
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Razer Tartarus Keypad 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested not hall effect and very expensive}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Redragon K668 RGB Gaming Keyboard Wired 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2023 untested 108 Keys Mechanical Keyboard w/Extra 4 Hotkeys Upgraded Hot-swappable Socket，Red Switch}}
|-
| &lt;!--Description--&gt;Redragon K689 PRO Wireless 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2024 untested Gasket RGB Gaming Keyboard, 108 Keys Mechanical Keyboard w/Extra 4 Hotkeys, Upgraded Hot-swappable}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2027 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Risophy 60
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2024 75% mechanical, hotswap so okay for price untested }}
|-
| &lt;!--Description--&gt;Risophy 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2028 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Royal Kludge RK65 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested cream switches }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2028 magnetic hall effect software should be better and surpasses mechanical}}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;SINO WEALTH Gaming KB SkyLion K68 
| &lt;!--Vendor ID--&gt;0x258a
| &lt;!--Product ID--&gt;0x003a
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| blue stalks with rgb lighting}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;SKYLOONG GK104 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested gateron }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2028 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;SteelSeries 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;TeckNet x300 2.4G Keyboard Mouse MosART 
| &lt;!--Vendor ID--&gt;0x062A
| &lt;!--Product ID--&gt;0x4101
| &lt;!--Revision--&gt;0312 
| &lt;!--Opinion--&gt;{{Yes|1 AAA for each and works well - mouse slightly better built than keyboard rubberised membrane}}
|-
| &lt;!--Description--&gt;TeckNet X331 HDE 2.4G Keyboard wireless RCMCU 
| &lt;!--Vendor ID--&gt;0x0C45
| &lt;!--Product ID--&gt;0x7000
| &lt;!--Revision--&gt;0001
| &lt;!--Opinion--&gt;{{Yes|wireless can be glitchy but few extra keys are mapped }}
|-
| &lt;!--Description--&gt;TeckNet X500 2.4G Keyboard Mouse MOSArt 
| &lt;!--Vendor ID--&gt;0x062A
| &lt;!--Product ID--&gt;0x2901
| &lt;!--Revision--&gt;0112 
| &lt;!--Opinion--&gt;{{Yes|works well especially large touchpad - usual rubber domed membraned keyboard mechanism }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Tecware Specter 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested good 75%}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2028 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Unicomp Model M USB 104 key 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }} IBM's and later Lexmark buckling spring switches 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Varmilo Minilo Bluebell (prestige silent) and Eculapytus (violet tactile)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2023 75% plastic build no screws not great to mod}}
|-
| &lt;!--Description--&gt;Varmilo Sword 68 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| expensive but good}} 
|-
| &lt;!--Description--&gt;Varmilo 98 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 expensive but good and Kailh silent}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2028 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Weikav Velocifire Choice65 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Weikav Velocifire Lucky65 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2028 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Wobkey Crush80 Reboot Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 very good but expensive Aluminum Hotswap Wireless RGB}}
|-
| &lt;!--Description--&gt;Wobkey Rainy 75
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 good 75% but not as expensive CNC Aluminum HMX/JWK/Cocoa Switches}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2028 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Wooting HE60 HE80 HE90 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 hall effect but expensive with good software}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2028 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;Womier WK61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2021 untested }}
|-
| &lt;!--Description--&gt;Womier Sk71 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024  }}
|-
| &lt;!--Description--&gt;Womier Sk75 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024  }}
|-
| &lt;!--Description--&gt;Womier Sk75 TMR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025  hall effect }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2028 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Xenta White Wireless HK6718B+HM3302--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Maybe|works with Raspberry Pi untested on AROS native}}
|-
| &lt;!--Description--&gt;Xinmeng X87 MAGIC_REFINER 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 untested keycap swap but not hotswapable switches}}
|-
| &lt;!--Description--&gt;Yunzii AL66 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| milk switches, cherry PBT, }}
|-
| &lt;!--Description--&gt;Yunzi B75 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 budget good with cocoa cream switches }}
|-
| &lt;!--Description--&gt;Yunzii AL75 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|good budget option with  swappable switches,  }}
|-
| &lt;!--Description--&gt;Yunzii AL80
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 switches }}
|-
| &lt;!--Description--&gt;Yunzi C75 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 budget good with  switches }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2028 magnetic hall effect software should be better and surpasses mechanical}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}

&lt;pre&gt;
linear  - creamy
tactile - thocky
clicky  - clacky 
&lt;/pre&gt;

&lt;pre &gt;
Cherry MX Black are linear switches (no feedback); good for gaming. 
Cherry MX Red are linear (less noise no click) but more squishy; 
Cherry MX Brown are in between Blue and Red in style and tactile; 
Cherry MX Clear switches have soft tactile feedback (with no click). 
Cherry MX Blue have tactile feedback with a click (noisy); good for typing. 

Gateron Yellows KS-3, KS-3x47 or better Pros have a milky top and black bottom and linear 

TTC Silent Frozen v2. Linear and dead silent 
Mouse the huano brown with yellow dot for silent mouse clicks
Kailh red dust proof encoder for smooth and close to silent scrolling
Boba U4 Silent Tactile switches
Husky linears

HMX 
&lt;/pre &gt;


=== Mouse ===

if the USB mouse is non-functional put a USB pendrive in before or add the following to user-startup in '''s''' drawer/folder/directory

 sys:prefs/trident NOGUI &gt; NIL:

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;10%&quot; | Brand
! width=&quot;20%&quot; | Description 
! width=&quot;10%&quot; | Model
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| 3Dconnexion 
| 3D Mouse 
| &lt;!--Model--&gt;[http://www.3dconnexion.com/products/spacenavigator.html SpaceNavigator]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}}
|-
| 3Dconnexion 
| 3D Mouse
| &lt;!--Model--&gt;SpacePilot Pro
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}}
|-
| 3Dconnexion 
| Mouse 
| &lt;!--Model--&gt;SpaceExplorer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}}
|-
| 3Dconnexion 
| Wireless Mouse 
| &lt;!--Model--&gt;SpaceMouse 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}}
|-
| &lt;!--Brand--&gt;3D Optical 
| &lt;!--Description--&gt;Wired 
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;0000:3825
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| Belkin
| Combo mouse
|
| 0x05FE
| 0x0011
| Low 0100
| {{yes|works}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;Cytec
| &lt;!--Description--&gt;Wired Mouse Gaming 
| &lt;!--Model--&gt;R.A.T 5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| Dell
| Mouse
| MO56UC
| 0x413C
| 0x3200
|
| {{yes|works}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;equatech / clone logitech  
| &lt;!--Description--&gt;wireless mouse
| &lt;!--Model--&gt;49779 / M185 
| &lt;!--Vendor ID--&gt; 3151:2020 later 3151:3020 
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{Yes|detected and works}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| Hama
| RF Optical Mouse
| AM-6000
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}}
|-
| &lt;!--Brand--&gt;Keychron 
| &lt;!--Description--&gt;Optical 
| &lt;!--Model--&gt;M3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;Keychron 
| &lt;!--Description--&gt;Optical 
| &lt;!--Model--&gt;M5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;Keycron 
| &lt;!--Description--&gt;Optical Wireless 
| &lt;!--Model--&gt;M6 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested 1k polling and 16k dpi }}
|-
| &lt;!--Brand--&gt;Keychron 
| &lt;!--Description--&gt;Optical Wireless 
| &lt;!--Model--&gt;M7
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested barebones 1k polling and 16k dpi, great for small hands, loud clicks}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;LogiCAD 3D
| &lt;!--Description--&gt;3D Mouse
| &lt;!--Model--&gt;Magellan 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| Logitech
| Cordless Desktop Navigator 
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{No|The Logitech Unifying Receiver pairing}}
|-
| Logitech Inc.
| First/Pilot Wheel Mouse
| N48/M-BB48 M-BE58 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested }}
|-
| Logitech
| Wireless mouse
| [http://www.logitech.com/en-roeu/mice_pointers/mice/devices/5484 M305]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{yes|works}}
|-
| Logitech
| Wireless RF Mouse
| MK710
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{No|The Logitech Unifying Receiver pairing}}
|-
| &lt;!--Brand--&gt;Logitech
| &lt;!--Description--&gt;Wireless Mouse 
| &lt;!--Model--&gt;MX Master Anywhere 2S 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{No|untested}} micro USB charge port on front 
|-
| &lt;!--Brand--&gt;Logitech 
| &lt;!--Description--&gt;Wireless 
| &lt;!--Model--&gt;M220 silent 
| &lt;!--Vendor ID--&gt;0x
| &lt;!--Product ID--&gt;0x
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|}}
|-
| &lt;!--Brand--&gt;Logitech Logi 
| &lt;!--Description--&gt;Optical 
| &lt;!--Model--&gt;MX Master 3S 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{No|2021 untested usb-c bluetooth, inbuilt battery but muted clicks}}
|-
| &lt;!--Brand--&gt;Logitach
| &lt;!--Description--&gt;Optical
| &lt;!--Model--&gt;G502 X Plus 
| &lt;!--Vendor ID--&gt;0x
| &lt;!--Product ID--&gt;0x
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2022 very clicky}}
|-
| &lt;!--Brand--&gt;Logitech
| &lt;!--Description--&gt;Optical 
| &lt;!--Model--&gt;MX Master 4 MXM
| &lt;!--Vendor ID--&gt;0x
| &lt;!--Product ID--&gt;0x
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Bluetooth usb-c dongle, inbuilt lithium battery}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Brand
| Description
| Model
| Vendor ID
| Product ID
| Revision
| Opinion--&gt;
|-
| &lt;!--Brand--&gt;Maxxter 
| &lt;!--Description--&gt;Wireless
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;248a:8566
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;Maxxter 
| &lt;!--Description--&gt;Wireless 
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;248a:8518
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;OrzerHome Maxxter 
| &lt;!--Description--&gt;Wireless 
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;248a:8514
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested 1 aa with no on/off switch }}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| Microsoft
| Wheel Mouse optical
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}}
|-
| Microsoft
| Sidewinder Mouse 
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}}
|-
| Microsoft
| IntelliMouse Explorer USB optical
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}}
|-
| Microsoft
| Wireless Optical Mouse 2000
|
| 0x045E
| 0x00F9 
|
| {{no|not working see keyboard Media Desktop 2000 above}}
|-
| &lt;!--Brand--&gt;Microsoft 
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;1461 1447 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{No|usb dongle matched to one mouse only no others}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;Razer
| &lt;!--Description--&gt;USB optical
| &lt;!--Model--&gt;Orochi 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}} 
|-
| &lt;!--Brand--&gt;Razer
| &lt;!--Description--&gt;USB optical
| &lt;!--Model--&gt;Mamba 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}} 
|-
| &lt;!--Brand--&gt;Razer
| &lt;!--Description--&gt;USB optical
| &lt;!--Model--&gt;Naga
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}} 17 buttons 
|-
| &lt;!--Brand--&gt;Razer
| &lt;!--Description--&gt;USB Optical
| &lt;!--Model--&gt;Naga Hex V2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}} MOBA Gaming Mouse, Professional Grade 16,000 DPI Sensor - RGB lighting 
|-
| &lt;!--Brand--&gt;Razer
| &lt;!--Description--&gt;USB optical 
| &lt;!--Model--&gt;DeathAdder 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}} 
|-
| &lt;!--Brand--&gt;Razer
| &lt;!--Description--&gt;USB optical
| &lt;!--Model--&gt;Viper 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}} 
|-
| &lt;!--Brand--&gt;Razer
| &lt;!--Description--&gt;USB optical
| &lt;!--Model--&gt;Basilisk V3 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested 1k polling, 35k dpi, }} 
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| Trust
| Slimline Lasermouse 
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}}
|-
| SteelSeries 
| Tobii EyeX EyeMobile PCEye 
| Eye Tracking Control 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}} gaze interaction track technology for augment augmentative and alternative communication (AAC). 
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;The Eye Tribe Tracker 
| &lt;!--Description--&gt;Eye 
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;USB Optical Mouse 
| &lt;!--Model--&gt;MV3000
| &lt;!--Vendor ID--&gt;0x192f
| &lt;!--Product ID--&gt;0x0916
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes|works}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|-
| &lt;!--Brand--&gt;
| &lt;!--Description--&gt;
| &lt;!--Model--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; {{N/A|untested}}
|}

=== Trackball ===
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;3Dconnexion SpaceBall 5000
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{N/A|untested}} Labtec designed and rolled into new company 3dconnexion 2001 by owners Logitech 
|-
| &lt;!--Description--&gt;ACCO Kensington Orbit optical F1233A 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Kensington Turbo Mouse 64210
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Clearly Superior Technologies. Model:CST 1000-RC
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Logitech Trackman Marble Mouse Wired USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Logitech Cordless Trackman Wheel 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Logitech Optical Trackman T-RB22 - Cordless 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Logitech M570 wireless
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Microsoft Trackball Mouse Optical 1.0 USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Microsoft X05-87473 Trackball USB Optical 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}


=== KVM ===
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;NanoKVM 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}


=== Gamepad ===

Controllers have mostly decided that the left analog joystick is keyboard equivalent of WASD and right joystick is your mouse. You also have 2 bumpers above the triggers. Shoot could be right trigger (so it doesn't involve taking your thumb off the right joystick). Face buttons for reloading or jump or other non-critical functions. Crank up the sensitivity and practice. 

Testing can be done with the TRIDENT Prefs, [https://devicetests.com/controller-tester html5], [https://greggman.github.io/html5-gamepad-test/ html5], or [https://gamepad-tester.com/ Tester]


==== Dinput Poseidon Default Plugin - Playstation(TM) style ====

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;35%&quot; |Description 
! width=&quot;5%&quot;  |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision
! width=&quot;10%&quot; |Merge with USB on Digital Pad
! width=&quot;10%&quot; |Analogue Hack with Analog Stick
! width=&quot;30%&quot; |Opinion
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Betop Betong Bat D2E BTP-BD2E XD4D2E
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;  
|- 
| &lt;!--Description--&gt;Gravis Eliminator Gamepad Pro USB  
| &lt;!--Vendor ID--&gt;047d
| &lt;!--Product ID--&gt;4005
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;{{N/A}}
| &lt;!--Opinion--&gt;2002 2d only 
|-
| Hama Black Force USB Gamepad
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{Maybe| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Maybe| }}
| &lt;!--Opinion--&gt;2003 psx clone look 
|- 
| &lt;!--Description--&gt;Jess Tech Game Elements Philips GGE909 PC Recoil Pad 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Merge with USB on Digital Pad
| Analogue Hack with Analog Stick
| Opinion
|-
| [http://www.youtube.com/watch?v=TCbAmIhj6P4 Logitech Wingman Precision USB] G-UC3B 
| &lt;!--Vendor ID--&gt;0x046d 
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{N/A| }} 
| 2002 no 3D but good for 2D retro games like Turrican II
|-
| &lt;!--Description--&gt;Logitech Wingman Action Pad G-UB3A 
| &lt;!--Vendor ID--&gt;0x046d
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Maybe|untested }} 
| &lt;!--Opinion--&gt;2002 1 blue lucid translucent - thin analog stick N64 type - 
|- 
| Logitech Wingman RumblePad UB05B
| &lt;!--Vendor ID--&gt;0x046d 
| 0xc20a
| 1.12
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Maybe|untesed }} 
| 2000 twin blue analogue sticks N64 type - poor 2d controls with single molded blue piece - vibration feedback - single shoulder buttons with throttle control below right one 
|-
| Logitech Wingman Cordless RumblePad G-RA4A 
| &lt;!--Vendor ID--&gt;0x046d 
| 0xc211
| 1.12
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Maybe|untested }} 
| 2001 twin blue analogue sticks N64 type - poor 2d controls with single molded black piece - vibration feedback - dual shoulder buttons L1 L2 R1 R2 with blue throttle control below right one - 4 aa mn1500 batteries; life not great - C-UD10A usb dongle - overall big and bulky 
|-
| &lt;!--Description--&gt;Logitech Precision Wired G-UG15
| &lt;!--Vendor ID--&gt;0x046d 
| &lt;!--Product ID--&gt;0x
| &lt;!--Revision--&gt;0x
| &lt;!--Merge with USB on Digital Pad--&gt;{{Maybe| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{N/A|N/A}} 
| &lt;!--Opinion--&gt;2002 psx styling blue outer shell - no 3D analog and no shoulder buttons - no rumble 
|-
| &lt;!--Description--&gt;Logitech Cordless Precision G-X2E14A
| &lt;!--Vendor ID--&gt;0x046d 
| &lt;!--Product ID--&gt;0x
| &lt;!--Revision--&gt;0x
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{N/A|N/A}} 
| &lt;!--Opinion--&gt;2002 ps2 styling blue outer shell - no 3D analog and no shoulder buttons - no rumble 
|-
| &lt;!--Description--&gt;Logitech G-X5C11A Cordless Precision Wireless Controllers
| &lt;!--Vendor ID--&gt;0x046d 
| &lt;!--Product ID--&gt;0x
| &lt;!--Revision--&gt;0x
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{N/A|N/A}} 
| &lt;!--Opinion--&gt;2002 psx styling black outer shell - no 3D analog and no shoulder buttons - no rumble 
|-
| [http://www.testfreaks.co.uk/game-console-accessories-controls/logitech-dual-actiontm-gamepad/ Logitech Dual Action] 
* G-UD8 has no mode (2D only?) button and no rumble 
* G-UF13A later 
| &lt;!--Vendor ID--&gt;0x046d 
| 0xc2
| 
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Yes|[http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=7018&amp;forum=12 G-UF13A tested only]}} 
| 2003 New body shape psx style - dual analog 3D sticks - 4 small travel shoulder triggers no 5,6,7,8 
|-
| Logitech RumblePad 2 G-UF13
| &lt;!--Vendor ID--&gt;0x046d 
| 0xc218
| 1.00
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Yes| }} 
| 2006 light blue top/black base - twin analogues 3D along with dual short travel shoulder buttons - rumble present - 
|-
| &lt;!--Description--&gt;[Logitech RumblePad 2 Cordless] 
* G-RC?? OLD version that take FOUR batteries and RED Logitech logo 
* G-RC14 uses TWO batteries has an ORANGE logo - dongle C-UE10 
| &lt;!--Vendor ID--&gt;0x046d
| &lt;!--Product ID--&gt;0xc219
| &lt;!--Revision--&gt;0x0200
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Yes|mostly}}
| &lt;!--Opinion--&gt;2008 may have to remove 1 battery - G-RC?? 5 + 7 buttons - G-RC14 use buttons 6 + 8 to reset sticks - replace battery and push large button on receiver - 
|- 
| &lt;!--Description--&gt;Logitech F310 Wired Dual Action G-U0001 
| &lt;!--Vendor ID--&gt;0x046d 
| &lt;!--Product ID--&gt;0xc21
| &lt;!--Revision--&gt;0x
| &lt;!--Merge with USB on Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Yes|D mode switch}} 
| &lt;!--Opinion--&gt;2010 dual analog 3D with pc-xbox/psx switch on back (only D works) - both rear shoulder RT LT buttons have excess travel - no rumble vibration - 
|-
| &lt;!--Description--&gt;Logitech F510 Wired G-UG0002 
| &lt;!--Vendor ID--&gt;0x046d 
| &lt;!--Product ID--&gt;0xc21
| &lt;!--Revision--&gt;0x
| &lt;!--Merge with USB on Digital Pad--&gt;{{Maybe| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Maybe| }} 
| &lt;!--Opinion--&gt;2010 dual analog with dual xbox pc/psx X/D switched compatibility modes - 
|-
| Logitech F710 Wireless / Cordless RumblePad 2 G-R0001 
| &lt;!--Vendor ID--&gt;0x046d 
| 0xc219
| 3.05
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Maybe| }} 
| When switch on top set to D and nano receiver for each controller to pair - 2 aa mn1500 batteries required - rumble support sometimes - rear back shoulder buttons excessive travel needed 
|- 
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Merge with USB on Digital Pad
| Analogue Hack with Analog Stick
| Opinion
|-
| &lt;!--Description--&gt;Megaworld 'TIME' USB pad
| &lt;!--Vendor ID--&gt;0x0735
| &lt;!--Product ID--&gt;0x9902
| &lt;!--Revision--&gt;Low 0100
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No |}}
| &lt;!--Opinion--&gt;2000 Poor quality
|-
| &lt;!--Description--&gt;Microsoft 
* SideWinder Precision Pro USB (1997)
* SideWinder Precision 2 (1998)
* Game Pad Pro (1999)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Microsoft Sidewinder Game Pad USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{yes| }}}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{yes| }}
| &lt;!--Opinion--&gt;[https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1149&amp;rowstart=140&amp;pid=5934#post_5931 must setup first]
|- 
| &lt;!--Description--&gt;Microsoft Sidewinder Gamepad X04 Freestyle 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;{{Maybe| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{N/A|N/A }} 
| &lt;!--Opinion--&gt;{{N/A|untested}} 1998 might need USB adapter 
|-
| &lt;!--Description--&gt;Microsoft Sidewinder X05 63895 92626 Flight stick
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{unk| }} 
| &lt;!--Opinion--&gt;{{Yes|2000 [https://ae.amigalife.org/index.php?topic=929.msg11309#new tested]}}
|-
| &lt;!--Description--&gt;Microsoft Sidewinder Flight Stick X08-58736 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Microsoft 
    Plug &amp; Play Game Pad (2000)
    SideWinder Joystick (2000)
    Game Pad 2.0 (2001)
    SideWinder Force Feedback 2 (2002)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2002 long-standing static buildup problem and Force Feedback 2 was the removal of the power brick 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| Saitek [http://www.testfreaks.co.uk/game-console-accessories-controls/saitek-ps1000/ PS1000 Cyborg V.1], [http://www.testfreaks.co.uk/game-console-accessories-controls/saitek-ps2700-rumble-pad/ PS2700] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2000 no rumble function 
|- 
| Saitek [http://www.youtube.com/watch?v=xG0v-hf6ZPA P2600] [http://compactiongames.about.com/od/hardware/tp/gamepads.htm P3600], 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2000 no rumble function
|- 
| Saitek P2900 wireless 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| {{N/A|untested but runs on 1 AA battery}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Merge with USB on Digital Pad
| Analogue Hack with Analog Stick
| Opinion
|-
| &lt;!--Description--&gt;Sony Batoh PS3 mini USB Wired hookup [http://ps3.jim.sh/sixaxis/usb/ SIXAXIS] 
*PCB  Ribbon      Notes
*Protos ALPS MSU Rev3 M3 and the later CBEH-1019
*?    SA1Q135A 	  for sixaxis
*PP4  
*V2   
*V25  
*VX   SA1Q146A    first dualshock 3 model
*VX   SA1Q147A    CECHZC2U (USA)
*VX35 SA1Q159A 	  
*VX3  SA1Q160A 	  
*VX?  SA1Q188A    
*VX4  SA1Q189A    shipped with a CECH-2504 datecode 0C 
*VX5  SA1Q194A    changed design ALPS, PS button changes
*VX6  SA1Q195A    red case, 
*VX7  SA1Q222A    superslims 2 ribbons
*VX8  SA1Q224A    superslims 2 ribbons 
| &lt;!--Vendor ID--&gt;0x054c
| &lt;!--Product ID--&gt;0x0268
| &lt;!--Revision--&gt;1.00 
| &lt;!--Merge with USB on Digital Pad--&gt;{{No|}}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No|}}
| &lt;!--Opinion--&gt;Sometimes detected but no support - no sixaxis features detected - mini usb lead will have varying results - 
|- 
| &lt;!--Description--&gt;Sony PS4 
*JDM JDS 001 010 011 
*JDM 030 040 055 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Sony PS5 Dual Sense 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Speed Link Strike 2 FX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Thrustmaster Firestorm Dual Power 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Yes|[http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=7018&amp;forum=12 only 1 axis joystick only]}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Trust Predator GM-1500 GM-1520
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Merge with USB on Digital Pad
| Analogue Hack with Analog Stick
| Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Haute42 M series Aluminum Metal Joystick Hitbox Controller Arcade Fighting Stick
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Haute42 T series 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Haute42 G series Gamefinger G12 G13 G16 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt; plastic - 
|- 
| &lt;!--Description--&gt;Haute42 S series 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;  thinner and lighter than G series 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Mad Catz sf2 fightstick 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Mayflash Datel Paewang Arcade Pro Stick 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Mayflash F300 Fighting Stick 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Mayflash F500 Fighting Stick 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Pico Flatbox GP2040-CE Hot Swappable Mini Hitbox Keyboard 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;  default it is configured for PS4 but before plugging usbc cable in, X for Dinput, B Xinput, RT HID - plastic build case - Rev4 based on RP2040 chip and firmware is based on GP2040-CE (Community Edition) - 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Shenzhen Onebitdo Tech 8bitdo Fighting stick 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Venom 8 button 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
|}


==== Xinput Xbox Style Plugin ====

2018 extension added originally called AROSx but later redacted. Latest [https://github.com/medusalix/xone linux driver] might be useful. 

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;35%&quot; |Description 
! width=&quot;5%&quot;  |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision
! width=&quot;10%&quot; |Merge with USB on Digital Pad
! width=&quot;10%&quot; |Analogue Hack with Analog Stick
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;8bitdo Ultimate C Wired 82CB (Shenzhen ONEBITDO TECH - GWOWO) 
| &lt;!--Vendor ID--&gt;0x2dc8 
| &lt;!--Product ID--&gt;0x3106 
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2022 - 4 t6 torx screws - non hall effect so drifting issues - triggers go faulty often - 
|- 
| &lt;!--Description--&gt;8bitdo Ultimate 2C Wired Controller 82CD 
| &lt;!--Vendor ID--&gt;0x2dc8 
| &lt;!--Product ID--&gt;0x310A
| &lt;!--Revision--&gt;0114
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2024 - HID keyboard assigned - 4 t6 torx screws - hall effect analogs and triggers  - 1000Hz polling - 
|- 
| &lt;!--Description--&gt;8bitdo Ultimate 2C wireless 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2024  - 400mw battery - hall effect 3d nubs and triggers - micro switch shoulder buttons - d-pad poor for retro games - 
|- 
| &lt;!--Description--&gt;8bitdo ULtimate Mini Wired Controller for Xbox 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 hall effect 
|- 
| &lt;!--Description--&gt;8BitDo Pro 2 
*Wired Controller 
*Wireless
*Bluetooth
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 hall effect - playstation style layout for pc - slide button for S-A-D-X switch, android, dinput or xinput -  
|-
| &lt;!--Description--&gt;8BitDo Pro 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2025  tmr hall effect analogs, hall effect triggers and some microswitches - button swap - ps2 style layout - 
|- 
| &lt;!--Description--&gt;8bitdo Ultimate 3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2026  - mw battery - hall effect 3d nubs and triggers - micro switch shoulder buttons - d-pad  for retro games - 
|- 
| &lt;!--Description--&gt;8BitDo Pro 3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2026  hall effect analogs, hall effect triggers and some microswitches - button swap - ps2 style layout - 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Ace Aurora 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2025 hall effect joysticks with no deadzone mode, gyro, linear rumble, trigger stops, back paddles, button swap, macro, turbo, RGB LED effects -  tri-mode connection - 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Betop Beitong Spartan BTP-2270U 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;  no hall effect 
|- 
| &lt;!--Description--&gt;Betop Betong Asura 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;  no hall effect - noble linear trigger potentiometer and alps shoulder LB/RB micro switch 
|- 
| &lt;!--Description--&gt;BEITONG ASURA 2 Pro+ Game Controller Wireless Gamepad
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Beitong Zeus 2  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;BebonCool Dinofire Model Number: Q218 / TP28
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2021  - triggers aren't progressive but ON/OFF - 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;EasySMX X05 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 hall effect analog and triggers - tri mode connection - 
|- 
| &lt;!--Description--&gt;EasySMX Wireless Controller PC PS3, 9013pro ESM-9013PRO
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 linear hall effect but device sometimes will not connect tried multiple attempts with the dongle
|- 
| &lt;!--Description--&gt;EasySMX X10 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;EasySMX X20 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 ABXY MICRO SWITCH - Bumpers Tactile switch Hall Effect analog 
|- 
| &lt;!--Description--&gt;EasySMX X15 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2025 hall effect analog and triggers - membrane buttons - 
|- 
| &lt;!--Description--&gt;EasySMX S10 Wireless Gamepad 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2025 TMR Hall effect and compatible with Switch 2/PC/Phone/TV/Steam, NFC, Gyro, HD Rumble - 
|- 
| &lt;!--Description--&gt;EasySMX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;202
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Fantech World EOS Pro WGP15 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 hall effect trigger and sticks,2 back paddles, motion controlling 
|- 
| &lt;!--Description--&gt;Fantech EOS PRO II S 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2025 controller with TMR hall effect analogues, mechanical face buttons and D-pad, 63 input macro, back paddles, turbo - analog triggers with trigger stops - tri mode bt wifi and wired - slide switch on back for switch, macos/android and xinput - 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Flydigi Apex 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2023  luxury model 
|- 
| &lt;!--Description--&gt;Flydigi Vader Pro 3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2023 the Pro(Hall Effects) and Non-Pro (No Hall) 
|- 
| &lt;!--Description--&gt;Flydigi Direwolf 2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2023 hall effect sticks and triggers - poor wifi connection - 
|- 
| &lt;!--Description--&gt;Flydigi Apex 4
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2024  luxury model 
|-
| &lt;!--Description--&gt;Flydigi Vader 4 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2024 - hall effect, DInput mode (o+A hold) - 
|- 
| &lt;!--Description--&gt;Flydigi Direwolf 3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2024 hall effect analog and triggers but membrane buttons with gold contacts - 800mhA battery - 
|- 
| &lt;!--Description--&gt;Flydigi Dunefox 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2024 basic model hall effect analog and triggers but membrane buttons - 500mha battery - no gyros - 
|- 
| &lt;!--Description--&gt;Flydigi Vader 5 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2025 - hall effect stick with tension control, linear triggers, DInput mode (o+A hold) - 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Gamesir T4K Keleid, T4C Cyclone wired 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2023 poor to ok switch 
|- 
| &lt;!--Description--&gt;Gamesir Nova 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{no|| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{no| }}
| &lt;!--Opinion--&gt;2024 - switch type layout 
|- 
| &lt;!--Description--&gt;Guangzhou Chicken Run Network Tech Nova Lite GameSir-T4n LITE - Zikway HID gamepad
*[https://www.reddit.com/r/Gamesir/comments/1c185ve/psa_keep_gamesir_nova_lite_t4n_lite_firmware_at/ fw 4200 seems to be xbox so B then Home for Xinput (green LED), A then Home for HID BT Android (green/yellow LED), Y then Home for Switch Pro (Red LED)] or X then Home for Wifi and start and select to alternatively swap modes 
* and if on [https://www.reddit.com/r/Gamesir/comments/1c185ve/psa_keep_gamesir_nova_lite_t4n_lite_firmware_at/ fw 5700 ds4 so Home + B (blue LED), ]
* firmware 6900 
| &lt;!--Vendor ID--&gt;0x3537
| &lt;!--Product ID--&gt;0x1040 0x1041
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{no| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{no| }}
| &lt;!--Opinion--&gt;2024 - hall effect 3d nubs - no usb-c cable - rubber membrane analog trigger travel and bumpers shoulder buttons - wifi 2.4G and bluetooth - xbox layout so ab and xy might need to be swapped via m and a buttons for switch type [https://www.youtube.com/watch?v=po-nNuC5fps fixes video] - 250Hz polling - 600mah battery - rigid carry case - poor d-pad esp diagonals - gamesir settings software only on android 6+ or ios based only - 
|- 
| &lt;!--Description--&gt;Gamesir Nova 2 Lite  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;GameSir G7 SE Wired Controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 hall effect 
|- 
| &lt;!--Description--&gt;GameSir G8 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Gamesir TEGENARIA T3 Lite Wired 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 playstation aesthetic hall effect analog and membrane buttons - X+Home button connects as an Xbox controller
|- 
| &lt;!--Description--&gt;GameSir Cyclone 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 TMR Joysticks with anti-friction rings and metal anti-friction rings around the stems, gyro, rumble, macro, turbo, 2 back paddles, hall analog triggers with micro-switch trigger - tri mode bluetooth, 2.4GHz wifi and wired, 1000hz polling rate - gamesir connect software - 
|- 
| &lt;!--Description--&gt;GameSir G7 Pro for Xbox 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 TMR hall effect - hall effect triggers, tri mode connection - gamesir nexus software - 
|-
| &lt;!--Description--&gt;GameSir Super Nova Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2026 hall effect sticks and triggers, 1000Hz polling, tri mode connectivity, 
|- 
| &lt;!--Description--&gt;GameSir 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;GameSir 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;GameSir 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;GuliKit 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;GuliKit KingKong 2 NS08 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;Electromagnetic Stick hall effect - hall linear triggers - Mechanical face buttons - wired and wireless - Built-in rechargeable lithium battery 
|-
| &lt;!--Description--&gt;GuliKit KingKong 2 PRO NS09
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;hall efect - wired and wireless - Mechanical face buttons - Built-in rechargeable lithium battery 
|-
| &lt;!--Description--&gt;GuliKit KingKong MAX 3 KK3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;hall effect - wired and wireless - lithium battery - 
|-
| &lt;!--Description--&gt;Gulikit KK3 Max USB-c Bluetooth Controller
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 Hall Joysticks and Triggers, Maglev/Rotor/HD Vibration, 1000Hz Polling Rate, 4 Back Buttons,  
|- 
| &lt;!--Description--&gt;GuliKit KK3 PRO 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2024 smaller version of KK3 MAX - hall effect analog and triggers, face buttons , maglev rumble, gyro, 4 back paddles - rigid case - 950mAh up to 8 hrs - 
|-
| &lt;!--Description--&gt;GuliKit 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Hyperkin 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Hori EX2 Turbo UHX3-45 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Machenike G1 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 Wireless Gaming Controller with 1K Polling Rate Hall Effect Trigger Joystick For Nintendo Switch PC iOS Android 
|- 
| &lt;!--Description--&gt;Machenike G5 Pro Wireless Gaming Controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 ABXY Switch Membrane, Bumpers Tactile switch and hall effect analog 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;microsoft sidewinder precision pro 
| &lt;!--Vendor ID--&gt;0x045E
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| [https://pineight.com/mw/index.php?title=USB_game_controllers Xbox 360 Wired Controller]
| 0x045e
| 0x028e
| 0x
| &lt;!--Merge with USB Digital Pad--&gt;{{No|needs specific driver and has poor 2D control pad}}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|- 
| Microsoft (R) [https://blog.tkjelectronics.dk/2012/12/xbox-360-receiver-added-to-the-usb-host-library/ Xbox 360] (TM) Wireless Receiver for Windows(R) Model 1086 and Controller 
| 0x045e 
| 0x0719, 0x or 0x0291
| 0x0100
| &lt;!--Merge with USB Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;{{No|separate standalone usb dongle detected and shows as 8 vendor interfaces but no class associated and so not working - may need new class from code from xpad or xboxdrv to work the controllor}}
|-
| &lt;!--Description--&gt;Xbox 360 Kinect [http://hackaday.com/2010/11/10/kinect-open-source-driver-demo-and-hacking/ Video] 
[http://git.marcansoft.com/?p=libfreenect.git;a=commit;h=7655fcf7239ba4907654089dba535a196685dbe5 GIT]
| &lt;!--Vendor ID--&gt;0x045E
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2007  proprietary 2.4GHz RF protocol, 
|- 
| &lt;!--Description--&gt;Xbox One Wired Controller 
| &lt;!--Vendor ID--&gt;0x045E
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{no| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{no| }}
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Xbox One wireless controller newer model with the 3.5mm headphone jack 1537 1697 and microsoft adapter 
| &lt;!--Vendor ID--&gt;0x045E
| &lt;!--Product ID--&gt;0x02d1 or 0x02dd
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{no| }}
| &lt;!--Opinion--&gt;2014 
|- 
| &lt;!--Description--&gt;Microsoft Elite Series 1
| &lt;!--Vendor ID--&gt;0x045E
| &lt;!--Product ID--&gt;0x02e3
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{no| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{no| }}
| &lt;!--Opinion--&gt;2016 ok - 
|-
| &lt;!--Description--&gt;Xbox later models 1708+ Xbox One and Series use 5GHz and use Bluetooth, 
| &lt;!--Vendor ID--&gt;0x045E
| &lt;!--Product ID--&gt;0x02e0
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{no| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{no| }}
| &lt;!--Opinion--&gt;2017 
|- 
| &lt;!--Description--&gt;Xbox One S
| &lt;!--Vendor ID--&gt;0x045E
| &lt;!--Product ID--&gt;0x02ea 0x02fd
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{no| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{no| }}
| &lt;!--Opinion--&gt;2019
|- 
| &lt;!--Description--&gt;Microsoft Elite Series 2 Core 
| &lt;!--Vendor ID--&gt;0x045E
| &lt;!--Product ID--&gt;0x02ff
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{no| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{no| }}
| &lt;!--Opinion--&gt;2022 ok - no hall - 125Hz polling - 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Minisform MGP01 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;MOBAPAD N1HD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 has liquid silicone face buttons, hall effect analog, D-Pad swap, two back paddles, USB-A dongle, HD Rumble - 
|- 
| &lt;!--Description--&gt;Mobapad Huben 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2025 
|- 
| &lt;!--Description--&gt;Mobapad 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;BIGBIG WON Gale 墨将 mòjiāng 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;BIGBIG WON Blitz PRO 2 TMR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;BIGBIG WON now MOJHON AETHER 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2025 hall effect joysticks, hall effect triggers, mechanical bumpers, 1000hz polling rate, mechanical D-pad, membrane face buttons, mechanical back paddles, rumble, deadzone issues - tri mode 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;MSI FORCE GC20 GC30 V2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2021 not hall effect 
|- 
| &lt;!--Description--&gt;MSI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Mytrix Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;NACON GC-100XF Controller
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 average 
|- 
| &lt;!--Description--&gt;PXN P5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 hall effect joysticks &amp; triggers, limited trigger stops, 1000hz polling rate on wired, 4 back paddles, 32 macro record, anti-deadzone mode, RAW mode, gyro, turbo, tri-mode connection - 
|- 
| &lt;!--Description--&gt;PXN P50L 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;PowerA 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;QRD Stellar T5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;QRD Junior E5 Mini 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;QRD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Razer Wolverine V3 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024  hall 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;RetroFlag 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Speedlink XEOX Pro Analog Wireless 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;enclosed lithium battery? - xbox layout - switchable on back of controller to directinput (dinput) or xinput - USB dongle switchable to pc and ps3 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;SCUF Instinct Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2022 good 
|- 
| &lt;!--Description--&gt;SCUF Envision Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2023 good 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Steel Series Stratus Duo XL 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;usb adapter needed 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;[https://inputlabs.io/Inputlabs InputLabs Alpakka Open Source and build yourself] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;DIY it with 3d printer, pcb and components  - pi pico needed - 2 gyros for better accuracy - 
|- 
| &lt;!--Description--&gt;[https://inputlabs.io/kapybara Inputlabs kapybara] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;DIY one handed version wip 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Vilcorn Z03 BT Wireless 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt;2024 - other Bluetooth modes (green, red, blue, purple, etc.) Select + M1 (or M2) - 400mAh - not great latency wired - 800mhz polling -  
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;zd ultimate legend 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;zd 0+ elite 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 
|- 
| &lt;!--Description--&gt;zd 0+excellent
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;2024 
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
|}

&lt;pre&gt;
#ifndef AROSX_LIBRARY_H
#define AROSX_LIBRARY_H

#include &lt;exec/types.h&gt;

#define AROSX_CONTROLLER_TYPE_UNKNOWN  0x00
#define AROSX_CONTROLLER_TYPE_GAMEPAD  0x01

#define AROSX_GAMEPAD_DPAD_UP          0x0001
#define AROSX_GAMEPAD_DPAD_DOWN        0x0002
#define AROSX_GAMEPAD_DPAD_LEFT        0x0004
#define AROSX_GAMEPAD_DPAD_RIGHT       0x0008
#define AROSX_GAMEPAD_START            0x0010
#define AROSX_GAMEPAD_BACK             0x0020
#define AROSX_GAMEPAD_LEFT_THUMB       0x0040
#define AROSX_GAMEPAD_RIGHT_THUMB      0x0080
#define AROSX_GAMEPAD_LEFT_SHOULDER    0x0100
#define AROSX_GAMEPAD_RIGHT_SHOULDER   0x0200
#define AROSX_GAMEPAD_A                0x1000
#define AROSX_GAMEPAD_B                0x2000
#define AROSX_GAMEPAD_X                0x4000
#define AROSX_GAMEPAD_Y                0x8000

struct AROSX_GAMEPAD {
    ULONG   Timestamp;
    UWORD   Buttons;
    UBYTE   LeftTrigger;
    UBYTE   RightTrigger;
    WORD    ThumbLX;
    WORD    ThumbLY;
    WORD    ThumbRX;
    WORD    ThumbRY;
};

#define AROSX_EHMB_CONNECT    0x00
#define AROSX_EHMB_DISCONNECT 0x01
#define AROSX_EHMF_CONNECT    (1L&lt;&lt;AROSX_EHMB_CONNECT)
#define AROSX_EHMF_DISCONNECT (1L&lt;&lt;AROSX_EHMB_DISCONNECT)

struct AROSX_EventHook {
    struct Node         eh_Node;
    struct MsgPort     *eh_MsgPort;
    ULONG               eh_MsgMask;
};

struct AROSX_EventNote {
    struct Message      en_Msg;
    ULONG               en_Event;
    APTR                en_Param1;
    APTR                en_Param2;
};

#endif /* AROSX_LIBRARY_H */
&lt;/pre&gt;


=== Joystick ===

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;10%&quot; |Merge with USB on Digital Pad
! width=&quot;10%&quot; |Analogue Hack with Analog Stick
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;CH Products CombatStick 568 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Cyborg X 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Logitech Extreme 3D
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| [Logitech Attack 3 Joystick] 
| 0x0464
| 0xC214
| 0205
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| {{yes|works}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;saitek X-52 x52 pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;saitek aviator 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Speedlink Competition Pro USB 
| 
|
| 
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| {{maybe|works but games not working &quot;out of the box&quot;}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Trust Predator QZ 501
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{yes|works}}
|-
| &lt;!--Description--&gt;Trust Predator TH 400
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{yes|works}}
|-
| &lt;!--Description--&gt;Trust Predator GM-2500 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{yes|works}}
|-
| &lt;!--Description--&gt;Trust XK 100
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}

===[https://github.com/JacKeTUs/linux-steering-wheels Gaming Racing Steering Wheels]=== 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;25%&quot; |Description 
! width=&quot;5%&quot;  |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision
! width=&quot;10%&quot; |Merge with USB on Digital Pad
! width=&quot;10%&quot; |Analogue Hack with Analog Stick
! width=&quot;40%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;  [https://www.usb.org/sites/default/files/documents/pid1_01.pdf USB PID standard not supported], 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Cammus C5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Fanatec CSL Elite 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;PS4 and Xbox - belt driven wheel - 30cm wheel swapping 
|-
| &lt;!--Description--&gt;Fanatec Club Sport 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt; top belt $600 £500 system 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;FFBeast 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Merge with USB on Digital Pad
| Analogue Hack with Analog Stick
| Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Genius TRIO RACER F1 Racing Wheel 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;Cheap and cheerful but not great - may need calibrating 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Hama PC Racing Wheel Thunder V18 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;Average 
|-
| &lt;!--Description--&gt;Hori Racing Wheel 3 with pedals 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;PS3 PC 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Logic3 PXU450 TopDrive GT450 Steering Wheel for PS3, PS4, XBox One and PC
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Merge with USB on Digital Pad
| Analogue Hack with Analog Stick
| Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Logitech MOMO 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;Very good 
|-
| &lt;!--Description--&gt;Logitech Driving Force GT 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Logitech Drive Force Pro DFP 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt; wheel 900 degree - weighs in at 15&amp;nbsp;lbs
|-
| &lt;!--Description--&gt;Logitech Formula Force EX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;200 degrees turn for the EX model is arcade-like driving - adds PS3 compatibility via the PSx/2 adaptor - weighs in at 9&amp;nbsp;lbs
|-
| &lt;!--Description--&gt;Logitech G25 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;   - needs external psu - 
|-
| &lt;!--Description--&gt;Logitech G27 PC/PS3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt; comes with gear shifter - needs external psu - 
|-
| &lt;!--Description--&gt;Logitech G29 PC PS3/PS4
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;  may need additional shifter - gear 900deg wheel / rumble - 3 peddle - needs external psu - 
|-
| &lt;!--Description--&gt;Logitech G920 PC XboxOne 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;  may need additional shifter - gear 900deg wheel / rumble - 3 peddle - needs external psu - 
|-
| &lt;!--Description--&gt;Logitech G923 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Microsoft(R) SideWinder Precision Racing Wheel (1999)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Moza R3
| &lt;!--Vendor ID--&gt;0x346E
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Moza R5
| &lt;!--Vendor ID--&gt;0x346E
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Moza R9
| &lt;!--Vendor ID--&gt;0x346E
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Moza R12
| &lt;!--Vendor ID--&gt;0x346E
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;[https://github.com/Ultrawipf/OpenFFBoard OpenFFBoard], 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;PXN V10 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;PXN V12 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;PXN V12 Lite 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Merge with USB on Digital Pad
| Analogue Hack with Analog Stick
| Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Simagic M10 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt; base direct drive $900 £800 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Simplicity Simwheel 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt; direct 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Simucube 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Simucube 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Simucube 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Simxperience Accuforce V2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;SPEEDLINK Drift O.Z. Racing Wheel with Pedals and Gear Stick 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;SteelSeries Simraceway SRW-S1 Steering Wheel (PC) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Merge with USB on Digital Pad
| Analogue Hack with Analog Stick
| Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Thrustmaster Nascar Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Thrustmaster Ferrari Challenge Wheel 
| &lt;!--Vendor ID--&gt;0x044f
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt; Poor  
|-
| &lt;!--Description--&gt;Thrustmaster Ferrari FGT Rumble GT Experience 3-in-1 (PC/PS3)
| &lt;!--Vendor ID--&gt;0x044f
| &lt;!--Product ID--&gt;b658
| &lt;!--Revision--&gt;0102
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes|Wheel and all buttons detected}}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Maybe|}}
| &lt;!--Opinion--&gt;Not great - gear driven 240deg wheel rotation - no psu needed - 2 peddle - flappy gear change - rumble untested - red switch for PC PS3 selection 
|-
| &lt;!--Description--&gt;Thrustmaster F430 
| &lt;!--Vendor ID--&gt;0x044f
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Thrustmaster T500 RS Wheel 
| &lt;!--Vendor ID--&gt;0x044f
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt; belt driven wheel/rumble for GT5 
|-
| &lt;!--Description--&gt;Thrustmaster T60 Challenge 
| &lt;!--Vendor ID--&gt;0x044f
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Thrustmaster T150 Wheel 
| &lt;!--Vendor ID--&gt;0x044f
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;  gear / belt combo wheel / rumble - 2 peddle 
|-
| &lt;!--Description--&gt;Thrustmaster TMX Pro PC/XboxOne
| &lt;!--Vendor ID--&gt;0x044f
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;{{No| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| &lt;!--Opinion--&gt; direct drive rumble - no manual gear shift included 
|-
| &lt;!--Description--&gt;Thrustmaster T80 
| &lt;!--Vendor ID--&gt;0x044f
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;Base level and OK - PS4 - 270deg rumble - 2 peddle 
|- 
| &lt;!--Description--&gt;Thrustmaster T300 RS GT 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;PS3 PS4 - belt driven - 900deg rotation and modular 28cm wheel out - 2 peddles but 3 available 
|-
| &lt;!--Description--&gt;Thrustmaster TX Leather 
| &lt;!--Vendor ID--&gt;0x044f
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;TX Xbox version - 900deg rotation 
|-
| &lt;!--Description--&gt;Thrustermaster TS PC 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;PC only belt wheel 
|-
| &lt;!--Description--&gt; TS XW Racer PC Xbox1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt; top belt system 
|-
| &lt;!--Description--&gt;Thrustmaster T-GT 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;PS4 $700 £600 with T-DFB 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Merge with USB on Digital Pad
| Analogue Hack with Analog Stick
| Opinion
|-
| &lt;!--Description--&gt;Tracer Zonda Racing Steering Wheel PC PS3 Vibration Feedback Pedals Gearbox 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


===Gamepad Joypad Adapters===

* Most adapters will work in most OS's without installing a driver. Special functions needing drivers will be noted. 
* Some adapters do not work with some [http://www.stepmania.com/wiki/Dance_Pads dance pads] because of voltage issues. Other adapters map the dancemat arrows as axes and not as buttons, causing problems.
* If using an adapters should be compatible with '''original''' PlayStation PS/Xbox Xbox/GameCube GC /Dreamcast DC/Sega Saturn SS gamepads. 

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;35%&quot; |Description 
! width=&quot;5%&quot;  |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision
! width=&quot;10%&quot; |Merge with USB on Digital Pad
! width=&quot;10%&quot; |Analogue Hack with Analog Stick
! width=&quot;30%&quot; |Opinion
|- 
| &lt;!--Description--&gt;[http://www.maplin.co.uk/psx-usb-bridge-34887?tabid=3&amp;worldid=&amp;doy=21m9&amp;faqitem=playstation%20controller%20to%20pc%20adaptor Maplin] [http://www.rockfire.com.tw/ Padix Co. Ltd. Rockfire] PX-205 PSX/USB Bridge 
| &lt;!--Vendor ID--&gt;0x0583 
| &lt;!--Product ID--&gt;0x2050
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{Yes}} but buttons mapped different from others 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Maybe|poor}}
| &lt;!--Opinion--&gt;Ok with dpads, but very poor support with analogue hack 
|-
| Boom PS Joy Converter adaptor 
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;
| discontinued (2004/5). Hold Up, Start, and Select for three seconds. Very good [http://www.stepmania.com stepmania] recommendation. 
|-
| [http://www.hkems.com/m_main.htm EMS] [http://www.hkems.com/product/ps2/ps2-usb2.htm USB2] grey plastic box with 2 PSX ports, one on either side - UP and Select pressed for 3 seconds at the same time or the dance code (start+select+up) 
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes|Tests/joystick shows the PS port works in digital mode on d-pad}}
| &lt;!--Analogue Hack with Analog Stick--&gt;
| Set in PC switch mode. Does not work when using 2 pads at the same time, likely higher power requirements. FPSE emu DualShock untested, Mat and Guitar untested but known lag involved 
|-
| Joytech (play.com) (EMS USB2 bad clone) Black box twin PSX
| 0x0b43
| 0x0003
| 0x0
| &lt;!--Merge with USB Digital Pad--&gt;{{Maybe| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No|buggy hardware}} 
| but poor on dance ddr mat and guitar hero as the left and right keys do not like being pressed together, Dual shock untested 
|-
| [ EMS Trio Linker ] 1 PSone connection at bottom
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| 1PSX discontinued 2005 
|-
| [http://psxemulator.proboards.com/index.cgi?board=support&amp;action=display&amp;thread=421 EMS Trio Linker Plus] (blue box) 1 PSx at bottom
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| 1PSX discontinued 
|-
| Gamtec [http://www.gamestone.co.uk/gradius/guides_usb_smartjoy_guide.php SmartJoy Plus] Lik Sang PS-&gt;USB converter Red 2005 
| 0x0925
| 0x0005
| Low 0110
| &lt;!--Merge with USB Digital Pad--&gt;{{Maybe|detected and digital dpad works with [http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=4138&amp;forum=2&amp;post_id=35952#forumpost35952 joystick and testjoystick tests] but  the second analog control is not mapping correctly in digital mode}} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No|Analogue Hack - hardware buggy not useable}} 
| Dual shock untested, Mat and Guitar untested. Nothing picked up upon plugging it in. Quite common, these items have grounding issues or feed voltage back into the USB host and freeze the host controller, preventing any plugins or removals being detected. 
|-
| Gamtec SmartJoy Plus Dual PS-&gt;USB converter Red 
| 0x0925
| 0x00
| Low 
| &lt;!--Merge with USB Digital Pad--&gt;{{Maybe| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No|buggy hardware}}
| 
|-
| [http://uk.gear.ign.com/articles/700/700334p1.html Lik-Sang Super SmartJoy PSX] 
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| 1PSX 
|-
| Soyo Kiki Kiky 
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| 
|-
| eXcel PSX adaptor shaped a little like a stealth bomber with USB pass through 
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| 
|-
| Venom 
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| 
|-
| Dragon Plus (Radio Shack) Pantherlord GreenAsia USB to PS2/PS3 converter single black cable
| 0x0e8f
| 0x03
| 1.07
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Yes| }}
| 
|-
| Deal Extreme 2 PSX black cables from 1 USB port
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| {{N/A|untested }}
|- 
| &lt;!--Description--&gt;HDE 2014 Personal Communication Systems Inc 
| &lt;!--Vendor ID--&gt;0x0810
| &lt;!--Product ID--&gt;0x0001
| &lt;!--Revision--&gt;0106
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Same as single cable above but with black block midway along cable 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
|- 
| &lt;!--Description--&gt;TigerGame Ltd Mayflash PC001 Super Joy Box 3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| TigerGame Ltd Mayflash PC016 Super Joy Box arrowhead triangle twin PSX] Original was lack with RED Leds. Clones Dilong pu203, Blue HDE Neewer ShineData SD-APS2USB, Red Octane and Black PC Power Box (NS3454) '''embossed circle''' on top 
| 0x0810
| 0x0001
| 1.06
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes|Tests/joystick shows one PS port does not work with analog control at all but the other port does and maps correctly in digital mode}} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Yes|Analogue hack works }}
| Still available 2013, poor construction though, falls to pieces easily. Dual Shock untested, Mat and Guitar untested 
|-
| &lt;!--Description--&gt;TigerGame Ltd [http://www.mayflash.com/pc/pc038/pc038-1.htm Mayflash PC038 Super Joy Box Pro triangle twin PSX] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| TigerGame Limited Mayflash SuperJoy Box 5 PC006 long V-shaped 4 port PS/PS2 Game Controller Adapter  
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;
| 
|- 
| &lt;!--Description--&gt;TigerGame Limited Mayflash SuperJoy Box 5 PRO PC039 PS/PS2 Game Controller Adapter
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Merge with USB on Digital Pad
| Analogue Hack with Analog Stick
| Opinion 
|- 
| Boom PSX+N64 USB converter (purple or blue see through box) (2003/4) - red led for psx and green led for n64
| 0x6666
| 0x0667
| 0x0
| &lt;!--Merge with USB Digital Pad--&gt;{{No|not detected by Tests/joystick}}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No|Analogue hack }}
| Rumble Pak untested
|-
| [http://www.hkems.com/product/ps2/TrioLinkerPlus2.htm EMS Trio Linker Plus II] 
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }} [http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=4753&amp;forum=24&amp;post_id=43102#forumpost43102 ]
| &lt;!--Analogue Hack with Analog Stick--&gt;
| 1DC 1GC 1PSX but not for ddr mat games 
|-
| TigerGame Mayflash PC043 clone HuiJia Black twin N64 converter for PC USB 
| 0x0e8f
| 0x3013
| 0x0
| &lt;!--Merge with USB Digital Pad--&gt;{{No|detected by Tests/joystick though two digital pads have their settings wrong}} 
| &lt;!--Analogue Hack with Analog Stick--&gt;{{Yes|Analogue hack works well with middle handle/grip little joystick}}
| Rumble Pack untested 
|-
| TigerGame Mayflash PC MagicBox SuperBox 3 
| 
| 
| 
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| untested 1SS 1DC 1PSX }
|-
| &lt;!--Description--&gt;Lik Sang SmartJoy X 
| &lt;!--Vendor ID--&gt;0x045e
| &lt;!--Product ID--&gt;0x0285
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;SmartJoy X2 
| &lt;!--Vendor ID--&gt;0x045e
| &lt;!--Product ID--&gt;0x0289
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
| TigerGame Mayflash PC018 Super Joy Box 9 Xbox (NOT 360) 
| 0x05e3
| 0x060
| 
| &lt;!--Merge with USB Digital Pad--&gt;{{No|shows up as a Genesys Logic Hub}}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| does not work. Hub(s) 0x0288 detected but 0x0289 xbox1 joypads are not detected as hid let alone as [http://www.amiga.org/forums/archive/index.php/t-62940.html xpad] or [http://pingus.seul.org/~grumbel/xboxdrv/ linux xboxdrv driver] 
|-
| TigerGame Mayflash PC019 Super Joy Box 10 Xbox Twin ports (NOT 360) 
| 0x05e3
| 0x060
| 
| &lt;!--Merge with USB Digital Pad--&gt;{{No|shows up as a Genesys Logic Hub}}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| does not work with the big Fatty Duke or smaller S Akebono controller(s) 
|-
| TigerGame Ltd Mayflash PC020 Super Joy Box 11 Xbox Quad ports (NOT 360) 
| 0x05e3
| 0x0604
| 
| &lt;!--Merge with USB Digital Pad--&gt;{{No|shows up as a Genesys Logic Hub}}
| &lt;!--Analogue Hack with Analog Stick--&gt;{{No| }}
| 
|- 
| &lt;!--Description--&gt;TigerGame Ltd Mayflash PC035 3 in 1 Magic Joy box PS GC Xbox 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;USB to NES [http://wiki.nesdev.com/w/index.php/Standard_controller SPI like protocol] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Buffalo Classic USB Pad SNES like 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Mayflash PC044 USB to SNES 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;USB to MEGADRIVE GENESIS Joypad 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;[http://www.retrousb.com/product_info.php?cPath=21&amp;products_id=70 USB to 9 pin ATARI RETROPORT style JOYSTICK PORT] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;{{Yes| }} 
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Atari RetroLink 9pin to SB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;SLS Sega Saturn USB pad 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB on Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Mayflash PC050 Dual Saturn ports 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Guitar Hero for PC/Mac 
| &lt;!--Vendor ID--&gt;0x1430
| &lt;!--Product ID--&gt;0x474C
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;{{Yes| }}
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Cronus Max 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;BrookX One 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Mayflash Gamecube to USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;Mayflash Magic NS 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt; WiiU 
|- 
| &lt;!--Description--&gt;Brook Converter WiiU P3 P4 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt;CooV Xbox One Converter 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Merge with USB Digital Pad--&gt;
| &lt;!--Analogue Hack with Analog Stick--&gt;
| &lt;!--Opinion--&gt;
|-
|}


* [http://www.bemanistyle.com/forum/f6/best-metal-pad-19066/ Metal dance pads with LEDs] - My My Box Blue Shark (Nexen), Cobalt Flux (CF) (Let's Groove), Red Octane Afterburner, TX-2000, Logic3 (Dance Dance Dance), Gamerose (Stay Cool), 
* Hard foam mat - [http://www.mayflash.eu/3in1-deluxe-dansmat-ignition-foam-ps2xboxpc-p-5.html Mayflash] FutureMax Deluxe 3 in 1 Ignition, [http://www.gamerose.com/ Gamerose] (Stay Cool), TrinPad orange, 
* Soft foam mat - Logic3 (PS420N), [http://www.positivegaming.com/index.php?id=36 Positive Gaming Impact],  Gamerose Miss Daisys Naki (Stay Cool), Pelican, MadCatz

*PS1 PS2 PS3 PS4 flex ribbon big source of button/trigger issues with all controllers 
*PS2 Phat KSA1Q40A (Board), SA1Q33A (Membrane) SCHP-10010 H 
*PS2 SA1Q42A SCHP-10010 A 
*PS2 SA1Q43-A SCHP-10010 H


The primary axes are either the Control Pad or the left stick. Buttons come in a rough order: face buttons, then shoulder buttons, then Select and Start, then buttons under sticks, and finally Control Pad directions if not assigned to a hat. But the order and number of buttons within a category are unpredictable, as is which button the user expects to use for each action.

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;10%&quot; | Joypad 
! width=&quot;5%&quot; | HATS 
! width=&quot;5%&quot; | Button 01
! width=&quot;5%&quot; | Button 02
! width=&quot;5%&quot; | Button 03
! width=&quot;5%&quot; | Button 04
! width=&quot;5%&quot; | Button 05
! width=&quot;5%&quot; | Button 06
! width=&quot;5%&quot; | Button 07
! width=&quot;5%&quot; | Button 08
! width=&quot;5%&quot; | Button 09
! width=&quot;5%&quot; | Button 10
! width=&quot;5%&quot; | Button 11
! width=&quot;5%&quot; | Button 12
! width=&quot;5%&quot; | Button 13
! width=&quot;5%&quot; | Button 14
! width=&quot;5%&quot; | Axes 1 
! width=&quot;5%&quot; | Axes 2 
! width=&quot;5%&quot; | Axes 3 
! width=&quot;5%&quot; | Axes 4 
! width=&quot;5%&quot; | Axes 5 
! width=&quot;5%&quot; | Axes 6 
! width=&quot;10%&quot; | Comment 
|-
| [https://pineight.com/mw/index.php?title=USB_game_controllers Xbox 360 Wired Controller]
| 
| A (down-green) 
| B (right-red) 
| X (left-blue) 
| Y (up-yellow) 
| LB (white) 
| RB (black) 
| Back
| Start
| Guide 
| L3
| R3
| 
| 
| 
| Left X 
| Left Y
| LT
| Right X
| Right Y 
| RT 
| Poor 2D, Good 3D 
|- 
| &lt;!--Description--&gt;Gravis GamePad / Original PlayStation Controller 
| &lt;!--HATS DPAD--&gt; 
| &lt;!--Button 01--&gt;Red (Sqleft)
| Yellow X (X down)
| Green O (O right)
| Blue (Tri up)
| L1
| R1
| L2
| R2
| Select
| &lt;!--Button 10--&gt;Start
| 
| 
| 
| 
| &lt;!--Axes 1--&gt;Stick X
| Stick Y
| 
| 
|  
|  
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt; PlayStation 2 Older Adapters 
| &lt;!--HATS DPAD--&gt; 
| &lt;!--Button 01--&gt;Blue X (down) 
| Red O (right) 
| Pink Sq (left) 
| Green Tri (up) 
| L1
| R1
| L2
| R2
| Select
| &lt;!--Button 10--&gt;Start 
| Stick 1
| Stick 2
| 
| 
| &lt;!--Axes 1--&gt;
| 
| 
| 
|  
|  
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt; PlayStation 2 Newer Adapters 
| &lt;!--HATS DPAD--&gt; 
| &lt;!--Button 01--&gt;Up
| Right
| Down
| Left
| L2
| R2
| L1
| R1
| Select
| &lt;!--Button 10--&gt;Start
| Stick 1 (analogue Hack) 
| Stick 2 
| 
| 
| &lt;!--Axes 1--&gt;
| 
| 
| 
|  
|  
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt; Wish Technologies N64 Adaptoid 
| &lt;!--HATS DPAD--&gt; 
| &lt;!--Button 01--&gt; A
| C Down
| C Right
| B
| C Left
| C Up
| L
| R
| Start
| &lt;!--Button 10--&gt;Z
| Pad Up
| Pad Down 
| Pad Left
| Pad Right 
| &lt;!--Axes 1--&gt;Stick X
| Stick Y 
| 
| 
|  
|  
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt; 
| &lt;!--HATS DPAD--&gt; 
| &lt;!--Button 01--&gt;
| 
| 
| 
| 
| 
| 
| 
| 
| &lt;!--Button 10--&gt;
| 
| 
| 
| 
| &lt;!--Axes 1--&gt;
| 
| 
| 
|  
|  
| &lt;!--Opinion--&gt;
|- 
| &lt;!--Description--&gt; 
| &lt;!--HATS DPAD--&gt; 
| &lt;!--Button 01--&gt;
| 
| 
| 
| 
| 
| 
| 
| 
| &lt;!--Button 10--&gt;
| 
| 
| 
| 
| &lt;!--Axes 1--&gt;
| 
| 
| 
|  
|  
| &lt;!--Opinion--&gt;
|- 
|}

Just plug in your digital/analogue joystick or gamepad into USB port. The device will be handled by Poseidon USB stack. Poseidon is the USB stack with Trident adding a GUI (graphical user interface) prefs. 


the context sensitive page would come up right on pressing the help key inside the relevant window. The manual is in this archive, just in case it isn't in SYS:Locale/Help  


*How to change joystick mode to analogue?

By default a connected USB joystick emulates Amiga digital joystick. To change this behaviour so that the joystick is presented as analogue you need to use Trident preferences application (System:Prefs/Trident).

Open Trident and go to Devices on the left hand side (mouse click once on it). Select your controller from the list to the right and then click on Settings button below. This will open a new window. On the &quot;General&quot; tab find the &quot;Lowlevel Library Joypad Emulation&quot; section near the bottom. Find ports which are set to &quot;Merge with USB&quot; or &quot;Override with USB&quot; and change them to &quot;Analogue Hack&quot;. 

Please note that analogue joystick support is an extension of original Amiga functionality, thus an Amiga application must be explicitly written to use it. AROS SDL library uses this functionality, thus all SDL applications that use joystick, can use the analogue joystick feature.

The HID class has several options how to handle the input data: 

* Don't touch: The movement and button data for is not modified by the hid class. This is the default for the ports 0, 2, and 3. 

* Overwrite with USB: This will kill the  original  data  that  might  had  come  from  the internal  ports  and  overwrites it with the joypad data for this USB interface. Note well: If you have multiple  joypads  connected,  take care  which setting you have selected for each port, because only the last interface with this option will actually send the joypad data to the game. 

* Merge with USB: This option merges the input data of the  lowlevel.library  with  the USB  stream. This only works, if the connected device on the original Amiga  ports  is  NOT  a  mouse  (because  then   the   streams   are incompatible).  Merging  should  be  the preferred method, because it leaves the original joysticks working. 

* Disable: Turns off the port for the application.

* Analogue Hack: Tells Poseidon to force reporting  of  analogue  data  at  the  port. Please  note  that  this only works with programs that understand the analogue  data,  because  it's   an   extension   to   the   original lowlevel.library   standard   made  by  Commodore.  If  you  want  to incorporate this feature in your software, just contact me and I will send you the necessary information. 

* Rumble Port: As addition to the analogue data, the HID class  supports  applications and  games  that want to utilize a rumble pack or force feedback motors in the gamepads. This field selects to  which  lowlevel  port  the  hid device responds, when attempting to use the rumble pack. Normally, this corresponds to the port that has  been  set  in  the  actions  for  the joypad.


*How to change joystick port assignment?

The low  level  library  supports up to four ports. Port 0 is usually used by the mouse, port 1 is the standard port for joysticks/joypads. By default a connected USB joystick is present in Port 1. To change its location to Port 0 you need to use Trident preferences. 

Open Trident and go to Devices window. Select your controller from the list and then click on Settings button. This will open a new window. On the &quot;General&quot; tab find the &quot;Lowlevel Library Joypad Emulation&quot; section. Port 1 should be set as either &quot;Merge with USB&quot; or &quot;Override with USB&quot;. Change this setting to &quot;Don't touch&quot;. Change Port 0 setting to &quot;Merge with USB&quot;.

Go to &quot;Actions&quot; tab. In the &quot;Reports and collection&quot; select first entry named &quot;Joystick&quot;. in the &quot;Usage items&quot; select &quot;X axis&quot;. Go to &quot;Performed actions&quot; area. On the left there will be a list of triggers. Each of them should have (port1) in their params. Click on the first trigger and using buttons to the right of the list change port1 into port 0. Repeat this for all triggers and for all items on &quot;Usage items&quot; list.


*How to make joystick simulate keyboard keys?

With Poseidon it is possible to make the joystick simulate the keyboard pressings. This might enable using joystick for playing games which only have keyboard support. This feature is configured in Trident preferences.

Open Trident and go to Devices window. Select your controller from the list and then click on Settings button. This will open a new window. Go to &quot;Actions&quot; tab. On the right top window select X axis. On the left bottom list select an entry &quot;Digital Joystick, Push left(port 1)&quot;. On the panel to the right change &quot;Digital joystick&quot; into &quot;Raw Key&quot;. A list of keys will be displayed. Select key you wish to send. Repeat the same procedure for &quot;Digital Joystick, Release left (port 1)&quot; option but this time check &quot;Send key up even instead of key down&quot;. Open shell and move your joystick to the left - your selected letter should appear in the shell. 


*Analogue in Trident Prefs
* Open the Trident USB Prefs -&gt; Devices -&gt; Select your joypad -&gt; Settings button -&gt; Action TAB 
* See some &quot;axis&quot; listed under &quot;Usage items&quot; in the top right of the window. They are your analog stick(s) 
* Check [x] Track Incoming Events which is half way down the window on the left 
And you should see some axis activity in &quot;Usage items&quot; when you move the analog stick 


*Actions

HID class item -&gt; Settings -&gt; HID Class Window -&gt; Action Tab -&gt; Action handling area 

Reports and collections -&gt; Usage Items -&gt; Performed actions 


Qualifier keys are *special*. You don't only need to create the actual keypress but also modify the qualifiers.
Go to the keyboard panel and find the windows menu key by enabling key tracking and pressing the windows menu key. Then assign the right amiga key to it.

Go to the actions panel and find the right amiga key (it's called &quot;Keyboard right GUI&quot;). Remember the actions stored there, best write them down in exact order. Then delete them.
Find the windows menu item and add the missing qualifier action. Be sure the parameters are exactly the same and the order is right.

Set them to Raw, then assign an up and down button for each character, etc.
when you change the settings to RAW so you can assign keyboard strokes. it will always say, KEYDOWN or what ever on the left, it never provides and option for key release.

The problem still remains though that if I try to assign the Directional Pad (Hat) to Arrow Keys, that things will get screwed up and you either can not move with the directional PAD (HAT), or movements are assigned to the Left Analog, and do not work as they should, it's as if the right and down arrow keys are ALWAYS On, regardless of the fact that I did indeed assign a Key release command to each input.

check that by pressing analog directions and see the current values, and the thresholds configured in poseidon to bind them to left/right/up/down.

misconfigured too much stuff in the HID settings, you can always go in poseidon-&gt;config list entry and delete the config item related to your device (or the HID class setting itself), back to basics.


*Rumble in Trident Prefs
Open Trident Prefs and click on the Devices option in the left hand window. Click with the mouse once on your gamepad choice on the right hand side and again on the Settings button below. In the new window, select the '''General''' TAB and half way down on the right there is an &quot;Open Now&quot; button in the section &quot;HID output control window&quot;. Clicking on that button opens another window (HID Control) with sliders for the two rumble engines inside the controllers and you can test if they work. '''Sometimes clicking that button does nothing, other times it will open the window and say nothing is detected.''' The leftmost two sliders do nothing, the third one has a large rumble effect, and the fourth one has a small rumble effect.

===Graphic Drawing Tablet===

There is a standard in HID for tablets possibly mouse type. If the tablet is HID conforming in that sense, it should work. Aiptek does a fairly good job at this. The other competitor, Wacom, didn't pay too much attention to this and simply adapted their legacy serial protocol into HID in a very awkward way. Older Wacom tablets have worked with the special support in the HID class, but not the more recent ones. 

 to use graphic tablets fully, applications need to be written that make use of the AmigaOS NewTablet events (which AROS has) 


* Entry level - A6 (6x4) work area 
* Medium A5 (6x8) A4 (10x7) size   (recommended but only a few ie years 2000 to 2003 models supported) 
* Semi Pro A3 (12x9) 
* Pro  Cintiq


* 2005/6 Some support added for Wacom tablets  
* 2008 Wacom's patent on battery free pens expires


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;Micrograf Tabby (late 1980s and early 1990s) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based }}
|-
| &lt;!--Description--&gt;podscat pt 3030 graphics tablet
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based }}
|-
| &lt;!--Description--&gt;Summagraphics 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based }}
|-
| &lt;!--Description--&gt;Wacom IV compatible (Graphire, ArtPad, A3, A4, A5 and PenPartner CT-0405-P - Wacom intuos GD-0405-R) Waycom Digitiser II UD-0608-R
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based }}
|-
| &lt;!--Description--&gt;Wacom Artpad II (KT-0405-R) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based }}
|-
| &lt;!--Description--&gt;AceCad boards 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based }}
|-
| &lt;!--Description--&gt;AipTek HyperPen 6000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based }}
|-
| &lt;!--Description--&gt;Calcomp 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based }}
|-
| &lt;!--Description--&gt;AipTek HyperPen 8000 - Aldi/Medion MD 9310 and Aldi/Tevion LT 9310 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based }}
|-
| &lt;!--Description--&gt;Tablet PC penabled 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based like x61t X60t NC4200 NC4400 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|Serial RS232 based }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;
* Wacom PenPartner
* PenPartner 2
* PenStation 2
| &lt;!--Vendor ID--&gt;0x056a
| &lt;!--Product ID--&gt;0x0000
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Wacom Graphire - Wacom Tablet ET-0405-U UV1.1-1 (Slate Blue)  ET-0405UL (lime)  (orange)  (red)  (purple) 
| &lt;!--Vendor ID--&gt;0x056A
| &lt;!--Product ID--&gt;0X0010
| &lt;!--Revision--&gt;0100
| &lt;!--Opinion--&gt;{{Yes|late 90s with A6 size - [Wacom Support] of X-axis 00000-10205  Y-AXIS 0000-7421 Tip Pressure 000-511 under Trident prefs. Air pen mouse type movements }}
|-
| &lt;!--Description--&gt;
* Grapphire 2 4x5  ET-0405A-U UV2.0-3 (Steel Blue) 
* Graphire 2 5x7 ET-0507A 
| &lt;!--Vendor ID--&gt;0x056A
| &lt;!--Product ID--&gt;0x0011 and 0x0012
| &lt;!--Revision--&gt;0110
| &lt;!--Opinion--&gt;{{Yes|A6 and A5 versions - [Wacom Support] of X-axis 00000-10205  Y-AXIS 0000-7421 Tip Pressure 000-511. Air pen mouse type movements - mouse EC-120-0K tested}}
|-
| &lt;!--Description--&gt;Wacom Graphire 3
* cte-430/w 4x5 pearl   sapphire 
* cte 630 6x8 
| &lt;!--Vendor ID--&gt;0x056A
| &lt;!--Product ID--&gt;0x0013 and 0x0014 
| &lt;!--Revision--&gt;0314
| &lt;!--Opinion--&gt;{{Yes|A6 and A5 size - [Wacom Support] Xaxis 0-10207 yaxis 0-7423 tip pressure 0-511 and the erase end appears to respond but avoid bluetooth BT versions }}
|-
| Wacom Graphire 4 
* cte-440/B Blue cte 440/s Silver 4x5
* cte-640 6x8 cte 640 u 0403 
| &lt;!--Vendor ID--&gt;0x056A
| &lt;!--Product ID--&gt;0x0015 and 0x0016 
| &lt;!--Revision--&gt;403
| {{Yes|A6 and A5 work area detected [Wacom Support] x-axis 0000-10207 Y axis 0000-7423 Tip Pressure 000-511 and delete rub out end of the pencil seems detected but avoid bluetooth BT versions }}
|-
| &lt;!--Description--&gt;
* Wacom Intuos 4x5 GD-0405 
* Intuos 6x8    GD-0608
* Intuos 9x12    GD-0912
* Intuos 12x12  GD-1212-U 
* Intuos 12x18 GD-1218
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x0020 0x0021 0x0022 0x0023 0x0024 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Yes|detected and responses delivered back - x axis up to 30479 and y axis 31679, tip pressure up to 1023 and x and y tilt up to 127 - Wacom intuos GD-0912-A for Apple Macs NOT SUPPORTED}}
|-
| &lt;!--Description--&gt;
* Intuos 2 4x5 A6 - XD-0405-U 
* Intuos 2 6x8 A5 - xd 0608u uoc
* Intuos 2 9x12 XD-0912-U
* Intuos 2 12x12 XD-1212-U
* Intuos 2 12x18 XD-1218-U
| &lt;!--Vendor ID--&gt;0x056a
| &lt;!--Product ID--&gt;0x0041 0x0042 0x0043 0x0044 0x0045 
| &lt;!--Revision--&gt;0126
| &lt;!--Opinion--&gt;{{No|various sizes and recognised as [Wacom Support] but not working. x-axis 00000-20319 y-axis 00000-16239 tip presure 0000-1023 x-tilt y-tilt 000-127.  HID mouse xc-100-03 works but never could use it as a real tablet with pressure with TVPaint 3.6 }}
|-
| &lt;!--Description--&gt;
* Intuos 3 4x5 (PTZ-430) 
* Intuos 3 4x6   (PTZ-431W ) 
* Intuos 3 6x8   (PTZ-630 PTZ630) 
* Intuos 3 6x11 (PTZ-631W A3 wide)  
* Intuos 3 9x12 (A4 PTZ-930 PTZ930)  
* Intuos 3 
| &lt;!--Vendor ID--&gt;056a
| &lt;!--Product ID--&gt;0x00b0 0x00b1 0x00b2 0x00b3 0x00b4 0x00b5
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No}} Actions in HID setup window definitively locks the Pointer (mouse) reports settings and even after a clear and save, nothing changes, the configuration returns to default values.  &quot;[Wacom]&quot; reports don't see any events from the tablet, even with &quot;Pointer&quot; reports cleared and save, so is locked a in &quot;mouse&quot; state - but can send a special command to the tablet in order to put it into a special vendor mode. This mode enables Wacom specificities like pressure, tilt, absolute position, buttons, etc... you should send an HID report feature with ReportID=2 and data=2, the current HID class driver doesn't give a way to change that, even using the &quot;initial startup actions&quot; item in the extra collection. No listed features work 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Wacom Volito - Promethean FT-0405-U06 UV1.4-1 
| &lt;!--Vendor ID--&gt;0x056A
| &lt;!--Product ID--&gt;0x0060
| &lt;!--Revision--&gt;0141
| &lt;!--Opinion--&gt;{{Yes|A6 work area with [Wacom Support] of x-axis 0000-5103 Y axis 0000-3711 Tip Pressure 000-511. Air and touch mouse movement - appears to be the budget option with some but limited features}}
|-
| &lt;!--Description--&gt;Wacom Volito 2 
* CTF-??? 2x3 
* CTF-420G CTF-420 V2.0-0 4x5
* Serif Penabled 6742 rebadge of CTF 420/020-B CTF-420/02
| &lt;!--Vendor ID--&gt;0x056A
| &lt;!--Product ID--&gt;0x0062
| &lt;!--Revision--&gt;0200
| &lt;!--Opinion--&gt;{{Yes|A6 work area with [Wacom Support] of x-axis 0000-5103 Y axis 0000-3711 Tip Pressure 000-511. Air and touch mouse movement - no erase function on the end of the pen - nylon nibs value option}}
|-
| &lt;!--Description--&gt;
* Wacom PL-400 LCD 
* PL-500
* PL-510
* PL-550
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x0030 0x0031 0x0032 0x0034 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
* PL-600
* PL-600 SX
* PL-700
* PL-710
* PL-800
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x0033 0x0035 0x0036 0x0037 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Wacom Cintiq 21 UX and Cintiq Partner DTF-720
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;Wacom PenTablet Bamboo (MTE), Bamboo Craft (CTH), Bamboo Fun (CTE), Bamboo Pen (CTL) and Bamboo Pen &amp; Touch (CTH) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Wacom Bamboo Fun Medium CTE-650 
| 
| 0x0018 
| 
| {{Maybe|[http://www.a1k.org/forum/showthread.php?t=11432 works on a1k forum]}}
|-
| &lt;!--Description--&gt;Bamboo Fun Small CTE-450 white 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x0017 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Wacom Bamboo One CTF-430 V2.0-0 CTF 430/S
| &lt;!--Vendor ID--&gt;0x056A
| &lt;!--Product ID--&gt;0x0069
| &lt;!--Revision--&gt;0200
| &lt;!--Opinion--&gt;{{Maybe|A5 wired air pen and acts like a mouse only}}
|-
| &lt;!--Description--&gt;Wacom Intuos 4 
* Small PTK-440 PTK-540
* Medium - PTK-640 - PTK 540WL Wireless - 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested  Intuos4 surface sheet was revised in October 2010 to reduce nib wear}}
|-
| &lt;!--Description--&gt;Wacom Intuos 5 Touch 
*
* Medium - PTH-650 - USB Wired and Wireless Kit 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;0x0027 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested work, however wireless may glitch or drag }}
|-
| &lt;!--Description--&gt;Wacom Intuos Pro Medium - PTH-651 - 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Bamboo Small Pen Tablet - MTE 450 MTE-450A (MTE-450/k) - 
| &lt;!--Vendor ID--&gt;0x056A
| &lt;!--Product ID--&gt;0x0065
| &lt;!--Revision--&gt;0116
| &lt;!--Opinion--&gt;{{Maybe|A6 work area - mouse movement but no pen detection except x-axis 2 to -2 and y-axis 2 to -2 - mini usb lead - 4 blue led lit buttons not detected as well as circular touch button??  }}
|-
| &lt;!--Description--&gt;Bamboo Pen CTL 460
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested all Bamboo versions were criticized for the drawing surface's roughness (which got smoother over time), which caused the small pressure-sensitive 'nib' to wear down, and become slanted or scratchy in the same way as pencil lead, albeit more slowly}}
|-
| &lt;!--Description--&gt;Wacom Bamboo Fun CTH-461/S wired 
| &lt;!--Vendor ID--&gt;0x056A
| &lt;!--Product ID--&gt;0x00D2
| &lt;!--Revision--&gt;0106
| &lt;!--Opinion--&gt;{{Maybe|A6 size - Pen tracking not working but finger touch works }}
|-
| &lt;!--Description--&gt;Wacom Bamboo Connect Pen Tablet CTL-470 CTL-470K 470-DE 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;CTH 470K
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Wacom CTH 480/S wireless 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} lithium battery for pad - 
|-
| &lt;!--Description--&gt;Wacom Intuos Pen Small CTL-480/S CTL 480 K wired 
| &lt;!--Vendor ID--&gt;0x056A
| &lt;!--Product ID--&gt;0x030E
| &lt;!--Revision--&gt;0200
| &lt;!--Opinion--&gt;{{No|A5 detected as Intuos PS  but not working although the RHS blue led responds to pen on tablet }}
|-
| &lt;!--Description--&gt;CTH 490 PK S Photo - CTH-490CK-S Comic - CTH-490AK-S Art 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested lower hovering height pen nibs wear fast and input lag/responsiveness}}
|-
| &lt;!--Description--&gt;Intuos Pen &amp; Touch Medium - CTH-680 - USB Wired and Wireless Kit work 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Wacom Intuos Pro (PTH-660 and PTH-860) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;Waltop Media Tablet 10.6&quot;
    Genius G-Pen M609
    Genius G-Pen M609X
    iVista Media Tablet 10.6
    Aiptek MediaTablet 10000u

| &lt;!--Vendor ID--&gt;172f:0501
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Slim Tablet 12.1&quot;
| &lt;!--Vendor ID--&gt;0x172F
| &lt;!--Product ID--&gt;0x0034
| &lt;!--Revision--&gt;0x1105
| &lt;!--Opinion--&gt;{{yes|works}}
|-
| &lt;!--Description--&gt;Waltop Media Tablet 12 by 9&quot; 
    Aiptek HyperPen 12000u T-12000U Tablet Series 
    Nisis T-12000u USB Tablet Series Version 1.05 (aiptek rebadged)

    Trust item #1535
    ADESSO Cyber Tablet 12000 Graphic design tablet
    iVista Media Tablet 12
    PENTAGRAM O'pen Wide P 2003
    Genius G-Pen M712
| &lt;!--Vendor ID--&gt;172f:0500, 0x08ca
| &lt;!--Product ID--&gt;0x0010
| &lt;!--Revision--&gt;0105
| &lt;!--Opinion--&gt;{{Yes|detected with Nisis/Aiptek functioning as a tablet, untested with others  - Puck (mouse) x axis 0000 to 6000 y axis 0000 to 6000 - stylus (pen) x axis 00000 to 12000 y axis 00000 to 12000 tip pressure 0000 to 1023 - 16 function keys - AAA battery needed for pen and another for the mouse}}
|-
| &lt;!--Description--&gt;Waltop Media Tablet 14.1&quot; v5.1e
    Genius G-Pen M714X
    Aiptek MediaTablet 14000u WMK-H141 
    Trust item #15358
    Adesso CyberTablet 14000 M14
    iVista Media Tablet 14.1
    PENTAGRAM O'pen Wide P 2004

| &lt;!--Vendor ID--&gt;0X172f
| &lt;!--Product ID--&gt;0X0500
| &lt;!--Revision--&gt;0114
| &lt;!--Opinion--&gt;{{Yes|detected with Nisis/Aiptek functioning as a tablet - Stylus (Pen) X 16838 Y 16838 Tip Pressure 1023 }}
|-
| &lt;!--Description--&gt;Waltop PID 0038
    Genius G-Pen F509
    Manhattan 177405

| &lt;!--Vendor ID--&gt;172f:0038
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Waltop PID 0052
    Yiynova MSP19

| &lt;!--Vendor ID--&gt;172f:0052
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Waltop Q Pad
    Aiptek HyperPen Mini
    NGS Flexi Style
    VisTablet PenPad
    iVistaTablet Q Flex Pad
    Bravod Q-PD65-S
    Trust Flex Design Tablet (#16937)

| &lt;!--Vendor ID--&gt;172f:0037
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Waltop Sirius Battery Free Tablet
    VisTablet Muse
    PENTAGRAM Designer P 2700
    Princeton PTB-S1BK

| &lt;!--Vendor ID--&gt;172f:0502
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Waltop Slim Tablet 12.1&quot;
    Genius G-Pen F610
    Trust Slimline Widescreen Tablet (#16529)
    VisTablet Original 12&quot;
    Adesso CyberTablet Z12
    Adesso CT-Z12A
    PenPower Tooya Pro
    Aiptek Slim 12.1 Inch
    Aiptek SlimTablet 600u Premium II
    NGS Slim Proguess
    iVistaTablet Slim 12.1
    PENTAGRAM ThinType P 2006

| &lt;!--Vendor ID--&gt;172f:0034
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Waltop Slim Tablet 5.8&quot;
    Genius G-Pen F350
    Trust item #16485
    VisTablet Mini
    iVistaTablet Slim 5.8
| &lt;!--Vendor ID--&gt;172f:0032
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Waltop Venus S Tablet
    Trust eBrush Widescreen Tablet (#17939)

| &lt;!--Vendor ID--&gt;172f:0503
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Aiptek GmBH MediaTablet Ultimate II - 16:10 Professional Graphic Tablet Model 1400U 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;Hanvon Beijing HanWang HW Micro Drawing Tablet ET0504U 
| &lt;!--Vendor ID--&gt;0x0b57
| &lt;!--Product ID--&gt;0x8030
| &lt;!--Revision--&gt;01111
| &lt;!--Opinion--&gt;{{No|does not work - recognised as an HID mouse - no tablet extensions detected}}
|-
| &lt;!--Description--&gt;KYE EasyPen 340, Genius EasyPen 340 
| &lt;!--Vendor ID--&gt;0458:5014
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|untested }}
|-
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| Aiptek Hyper Pen 6000u PC Tablet APT
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{No|detected but does not work - win98 era cordless 6in by 4.5in - }}
|-
| &lt;!--Description--&gt;nisis T-8000U APT-2 Aiptek rebadge 
| &lt;!--Vendor ID--&gt;0x08CA
| &lt;!--Product ID--&gt;0x0021
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|A5 detected but no responses }}
|-
| &lt;!--Description--&gt;Acecad Flair II GT-504 Init Fkt  Fkt 0x5ab450c0
AIPTEK HyperPen 10000 U
Aiptek HyperPen 10000U, 
AIPTEK Slim Tablet U600 Premium II
| &lt;!--Vendor ID--&gt;0x0460
| &lt;!--Product ID--&gt;0x0004
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Ace Cad Enterprise Co., Ltd Tablet - 5x3.75 drawing area 
| &lt;!--Vendor ID--&gt;0x0460
| &lt;!--Product ID--&gt;0x0004
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Bosto's 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} UCLogic Digitizer 
|-
| &lt;!--Description--&gt;Adesso CyberTablet Z7, Adesso CyberTablet 12000, Adesso CT-12000A  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;UC-Logic / Lapazz WP8060, UC-Logic / Lapazz PF1209, UC-Logic / Lapazz Artistic Tablet 5540,   Manhattan 8&quot;x6&quot;, Manhattan 3&quot;x4&quot;, Manhattan
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested but suspect not working}}
|-
| &lt;!--Description--&gt;DigiPro 5.5×4” Graphics Tablet
Digital Ink Pad (A4 format) 
DigiPro WP8060, DigiPro WP5540,  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Genius G-pen
G-Pen 4500
Genius Wizardpen
Genius Mousepen
Genius Easypen i405 M610 
Genius PenSketch 9x12, Genius MousePen i608, Genius MousePen 8x6, Genius MousePen / WizardPen 5x4, 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Genius G-Pen F610
Genius G-Pen M610 
Genius G-Pen 340 (UC-LOGIC Tablet WP4030U)
Genius G-Pen 450 (UC-LOGIC Tablet WP5540U)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Genius
UC-LOGIC
iBall Tablet PF8060
iBall
Iball Pen Tablet 8060U, Iball Pen Tablet 5540U, Iball Pen Tablet 4030U, Iball Design Tablet PF1209,
NGS CADBOY (UC-LOGIC Tablet WP5540U)
Pentagram
QWare
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Trust TB-3100
Trust TB-5300 Trust 15356 
Trust TB-6300 Trust 15357  WP8060U  Slimline but bulky with metal backing A5 size 
Trust 16486, Trust 16447,  Sketch Design Tablet,
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|clashes with usb and crashes AROS }}
|-
| &lt;!--Description--&gt;UC-Logic Tablet WP1062
    Aiptek HyperPen 10000U
    Monoprice 10X6.25 Inches Graphic Drawing Tablet
    Pickle 10x6.25 Inch Graphic Drawing tabletguess

| &lt;!--Vendor ID--&gt;5543:0064
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| [ VTech KidiPhoto Art Studio] 
| 
| 
|  
| {{yes|works}}
|-
|}

Tablet has a squared lines of wires which induce a current into the pen which is then detected by the metal grid in the tablet pad. Tablets report pressure (and tilt on expensive models) and are absolute pointing devices (put the pen at the top left and the mouse pointer will go to the top left of the screen). Graphic drawing area, what keys, report rate, resolution lpi lpmm, accuracy, pressure levels (may come from the app), origin position,

Wacom tablets use electromagnetic resonance technology.  Since the tablet provides power to the pen through resonant inductive coupling, no power is required for the pointing device. As a result, no batteries are inside the pen (or the accompanying puck), making them lighter and slimmer.

Under the tablet's surface (or LCD in the case of the Cintiq) is a printed circuit board with a grid of multiple send/receive coils and a magnetic reflector attached behind the grid. In send mode, the tablet generates a close-coupled electromagnetic field (also known as a B-field) at a frequency of 531&amp;nbsp;kHz. This close-coupled field stimulates oscillation in the pen's coil/capacitor (LC) circuit when brought into range of the B-field. Any excess resonant electromagnetic energy is reflected back to the tablet. In receive mode, the energy of the resonant circuit’s oscillations in the pen is detected by the tablet's grid. This information is analyzed by the computer to determine the pen's position, by interpolation and Fourier analysis of the signal intensity.

In addition, the pen communicates information such as pen tip pressure, side-switch status, tip vs. eraser orientation and ID number (to differentiate between different pens, mice, etc.). For example, applying more or less pressure to the tip of the pen changes the value of the pen's timing circuit capacitor. This signal change can be communicated in an analog or digital method. An analog implementation modulates the phase angle of the resonant frequency, while a digital method is communicated to a modulator that distributes the information digitally. The tablet forwards this and other relevant tool information in packets, up to 200 times per second, to the computer.


If you disable (delete all of them except for one that needs to be set to &quot;no action&quot;, so that it will not be regenerated as default) the Extra Startup actions, the tablet should remain in relative mouse mode—you will not get pressure information in that mode though. [http://tech.groups.yahoo.com/group/highway_usb/message/2394]}}


=== Handheld Barcode Scanner Readers ===

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;Farsun 9100 barcode scanner 0-12&quot; 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Motorola Symbol LS2203 CMOS 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Tysso 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested Simple}} Code 11, Code 39, Code 93, Code 128, Coda Bar, UPC-A, UPC-E, EAN-8, EAN-13, MSI/Plessey, Telepen, Interleaved 2 of 5, Industrial 2 of 5, Matrix 2 of 5 
|-
| &lt;!--Description--&gt;Unitech MS320 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Wasp WCS3905 CCD 1&quot; 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} Code 93, Matrix 2 of 5, Industrial 2 of 5, Code 39, UCC/EAN-128, ISBN, Code 32, EAN/JAN-8 , EAN/JAN-13 , UPC-A, UPC-E, Codabar, Code 128, Code 11, Interleaved 2 of 5, MSI-Plessey, China Post, IATA 2 of 5, ISSN, UK-Plessey 
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;Datalogic Touch 90 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Intermec  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Honeywell Metrologic MK9540-32A38 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Motorola LS2208 Laser 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Wasp WWS800 Laser 1D 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;Datalogic GD4130-BK-C066 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Honeywell 1202G-1USB-5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Motorola / Symbol DS6707-DC20007ZZR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;DataMan 8000 2D 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Honeywell Voyager 9520/40 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Metrologic MS1690 USB 2D Barcode Scanner  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} QR Code GS1 Databar PDF417
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Syscan GM800 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}

[http://www.scandit.com/2011/11/04/types-of-barcodes-choosing-the-right-barcode-type-ean-upc-code128-itf-14-or-code39/ Types of Barcode]

&lt;pre&gt;
UPC-A       Grocery most common 
Code 128    
EAN-13      Library Books ISBN &amp; ISSN, 
Code 39     
Codabar     blood bank,

2D barcodes such as 
Data Matrix 
PDF417e     
Maxicode    
Aztec       
QR Code     old Nokia handsets, 
MicroPDF417 
&lt;/pre&gt;


===TouchScreens===

Projected capacitive (PCAP) touch screen product, amongst many options the widely used are I2C and USB 

*USB host–device structure which dominates consumer and industrial electronics devices where higher bandwidth needed and user-friendly (multiswipes)
*I2C Inter-Integrated Circuit simple serial standard for LCD display in embedded systems because of cost and low power 
*SPI arduino and rpi single boards 

We cover the USB here 

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| eGalax Touch 4a
| 0eef 
| 0001 
| 0001
| {{yes|2009 works}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Lilliput HDMI Monitors
669GL-70NP/C/T (7 inch)
869GL-80NP/C/T (8 inch)
FA1011-NP/C/T (10 inch)
FA1046-NP/C/T (10 inch)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Iilyama Prolite Monitors
PROLITE T1513SR-1 (15 inch)
PROLITE T1730 (17 inch)
PROLITE T1713SR-1 (17 inch)
PROLITE T1913SR-1 (19 inch)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Smart Display Company (SDC) Touchscreens TFT Monitors
TOUCH-TFT-TS07 (7 inch)
TOUCH-TFT-TS08 (8 inch)
TOUCH-TFT-TS10 (10 inch)
TOUCH-TFT-TS12 (12 inch)
TOUCH-TFT-TS15 (15 inch)
TOUCH-TFT-TS17 (17 inch)
TOUCH-TFT-TS19W (19 inch wide)
TOUCH-TFT-TS22W (22 inch wide)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;XENARC Monitors 7 inch models
700TSH
700TSU
700TSV
702TSV
705TSV
706TSA
700IDT
MDT-X7000
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;XENARC 
8 inch models:
800TSV
805TSV

10 inch models:
1020TSV
1026TSA
1040TS

12 inch models:
1200TS
1200TR
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;Asus VT229H 21.5&quot;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;CUQI 7&quot; Monitor Touchscreen 1024x600 IPS
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Espresso 15&quot; Portable Touchscreen Display Monitor
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Hannspree HT225HPB 21.5 inch
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;WaveShare 13.3inch HDMI LCD (H) (with case)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


===GPS tracking, running, cycling, biking, walking, hiking, ORIENTEERING, boaters and mapping===

Support for OpenStreetMap but not for Ordnance Survey, Map Pilot or National Geographic's Topo maps data gdb,

Data output supported nmea 0183 V1.5 APA, V1.5 XTE and V2.1 GSA formats, gpx, kml/kmz, tracks from tcx files, geo: URIs,  
NMEA0183(which is RS232, voltages range from -15 volts to 15 volts, 4800 baud), or need NMEA sentences connected to your computer

other method that some units support is a special serial cable that actually emits raw RS232 NMEA. These usually take 10-&gt;30 volts input, can run the unit, and have full voltage I/O for RS232 (not like spanner mode, which effectively turns the unit into a USB-&gt;Serial adapter inside the case).

Equivalent apps - merkator, mapsource,

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;Garmin gpsmap 180 GPS/chart plotter 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;1992 GARMIN GPS 55 AVD Portable System 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Garmin GPS V 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested - waas pinpoint within 3 metres - nmea - 4AA battery}}
|- 
| &lt;!--Description--&gt;Garmin GPS 12 12XL 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Garmin Legend C 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Garmin eMap 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|possibly through usbmodem rs232 connection nmea 0183 protocol}}
|-
| &lt;!--Description--&gt;Garmin eTrex 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}} rs232 these older units supported it and would provide the stream in either the standard NMEA 0183 format or a proprietary Garmin format.
|-
| &lt;!--Description--&gt;Garmin GPS 75 AVD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Magellan GPS Map 7000 model 45006 (1994) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Magellan GPS Tracker
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Magellan Pioneer Satellite Navigator 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Magellan GPS 300 315 320 Mentor Receiver (2003) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Not for dedicated sat nav units like the Nuvi, TomTom, etc 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;NaviLock NL-402U 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested u-blox 5 SuperSense® chipset with receivers for GPS, GLONASS, Galileo, BeiDou and QZSS}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;GM1-86UB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| U-BLOX UB-6010 GGA,GSA,GSV, RMC and support VTG, GLL, TXT ublox binary and NMEA Command Dynamic Condition }}
|-
| &lt;!--Description--&gt;NAVILOCK GPS NL-602U USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Yes|works via usbmodem.device - ublox ag 6 chipset - 50 channel}}
|-
| &lt;!--Description--&gt;TOPGNSS ton Receiver &amp; Antenna GM702  u-blox 7 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Yes|UBLOX7020 chip design bloc u-blox}}
|-
| &lt;!--Description--&gt;VK-162 G-MOUSE u blox 7 
| &lt;!--Vendor ID--&gt;0x1546
| &lt;!--Product ID--&gt;0x01a7
| &lt;!--Revision--&gt;0100
| &lt;!--Opinion--&gt;{{N/A|UBX G70xx with RMC VTG GSV TXT GLL GGA GSA}}
|-
| &lt;!--Description--&gt;VK-172 u-blox 7 G7020-KT gps gnss white pen stick receiver - over 1 inch long 
| &lt;!--Vendor ID--&gt;0x1546 
| &lt;!--Product ID--&gt;0x01a7
| &lt;!--Revision--&gt;0100 
| &lt;!--Opinion--&gt;{{N/A| detected as cdc controlled plug in device - 18x18x2mm patch antenna but can be slow to update - nmea 0183 and ublox binary protocol}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;GlobalSat BU-353 WaterProof USB GPS Receiver 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested SiRF Star III}}
|-
| &lt;!--Description--&gt;Haicom HI-206 USB GPS receiver with RS-232 interfaces, RJ11 and PS/II connector EB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|usb-serial prolific pl2303 detected but GSP3F SiRF Star IV technology not detected or bound}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;BT760Y, 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested Skytraq Venus 5 GPS chipset}}
|-
| &lt;!--Description--&gt;GM-65 USB GPS Receiver
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested Skytraq Venus 6 GPS chipset - 65 channel}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested Skytraq Venus 7 GPS chipset}}
|-
| &lt;!--Description--&gt;GM-65 USB GPS Receiver
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested Skytraq Venus 8 GPS chipset - 167 channels}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;Garmin Colorado 300 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}} USB 
|-
| &lt;!--Description--&gt;Garmin Geko 101 201 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}} limited waas enabled only - waypoints - aaa battery 
|-
| &lt;!--Description--&gt;Garmin Edge 200 bike mount 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Garmin ForeRunner 10 15 watch 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Garmin Montana 600
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Garmin Dakota 10 20 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Garmin Map76s 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Garmin Oregon 450T  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}} USB nmea 0183 
|-
| &lt;!--Description--&gt;Garmin eTrex 10 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested - no nmea0183 sentences data stream output - configuration an option to set it to &quot;Garmin&quot; mode, or &quot;Mass Storage&quot; mode. Since the mass storage mode seems to be required for waypoint/track/etc data exchange, the 'Garmin' mode would be for this data stream. Yet putting it in that mode doesnt seem to produce anything.}}
|-
| &lt;!--Description--&gt;Garmin Oregon 650T 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Garmin GPSMAP 64S 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Maybe|untested}}
|-
| &lt;!--Description--&gt;GPSMap 78S or GPSMap 76CSX which has a NMEA port for talking to Nav equipment
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Maybe|untested}}
|-
| &lt;!--Description--&gt;Garmin eTrex Vista Cx GPS Receiver 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested - 2AA battery}}
|-
| &lt;!--Description--&gt;Garmin GPSmap 276c
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Magellan 2000 XL 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Magellan 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Magellan 3000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Magellan Triton 300
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}} SiRFstarIII™, Antenna Type Multidirectional Patch with WAAS, EGNOS, MSAS support 
|-
| &lt;!--Description--&gt;Magellan Triton 400 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
|}


==massstorage.class (MSC/UMS - most cameras and mp3 players)==

=== USB Card Readers ===
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;15%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;15%&quot; |Installing
! width=&quot;15%&quot; |Booting
! width=&quot;30%&quot; |Opinion
|-
| A-Tec Model CR-362 
| 
| 
|  
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| {{N/A|untested}}
|-
| [http://www.belkin.com/IWCatProductPage.process?Merchant_Id=&amp;Section_Id=200406&amp;pcount=&amp;Product_Id=179164 Belkin 15 in 1 Card Reader]
|
|
|  
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| {{yes|works}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Conrad CP440 60 in 1 
| 
| 
| 
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| {{yes|works on a1k forum}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Genesys Gtech Logic 19 in 1
| 0x05E3
| 0x0710
| High 0200
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| {{yes|works}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Hama 19 in 1 Card Reader 
|
|
|  
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| {{yes|works}}
|-
| Hama 35 in 1 Card Reader 
|
|
|  
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| {{yes|works}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Integral Single Slot SD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Kingston USB 3.0 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Lexar microsd adapter 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} but wider than Sandisk version - could block other slot if below 
|-
| Pretec CardDriver 
|
|
| 
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| {{no|no driver}}
|-
| Sandisk MicroMate 
|
|
|  
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| {{yes|works}}
|-
| &lt;!--Description--&gt;Sandisk MobileMate SD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} 
|-
| &lt;!--Description--&gt;Sandisk MobileMate Micro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} has satisfying 'click' when microsd inserted 
|-
| &lt;!--Description--&gt;Sandisk MobileMate Duo MicroSD
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} no 'click' insertion uses pressure so future wear and tear issues 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Serena metal cased microsd only 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|Maybe}} hit or miss on quality 
|-
| &lt;!--Description--&gt;Serena &quot;Sandisk MobileMate&quot; look-alike 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|Maybe}} hit or miss on quality 
|-
| SilverCrest 16in1 
|
|
|  
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| {{yes|works}}
|-
| &lt;!--Description--&gt;Transcend 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Transcend P5 8 in 1 TSRDP5K 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Transcend P8 15 in 1 TSRDP8K
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Zyxel integralmemory 8 in 1 
| 0x0aec
| 0x3260
|  
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| {{no|not detected}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Installing--&gt;
| &lt;!--Booting--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}

=== USB Hard Drives ===
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Datel MaxDrive 
| 
| 
|  
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Inateck 2.5 Inch USB 3.0 Hard Drive Disk Enclosure/ Case (FE2001) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} Full USB 3.0 port but plastic teeth keeping drive in place can snap 
|-
| &lt;!--Description--&gt;Inateck case (FE2002) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} full USB 3.0 port - updated design 
|-
| &lt;!--Description--&gt;Inateck case (FE3001) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} wider USB 3.0 port and no on/off switch  Jmicron JMS578 chipset
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Iomega Desktop Hard Drive 500GB, 3,5“, USB2.0 
| 
| 
| 
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Samsung
|
|
|
| {{N/A|untested}}
|-
| Samsung
|
|
|
| {{N/A|untested}}
|-
| Samsung T3 SSD 
|
|
|
| {{N/A|untested}} USB 3.1 Gen 1 space grey / black metal/ plastic 
|-
| Samsung T5 SSD 
|
|
|
| {{N/A|untested}} USB 3.1 Gen 2 256GB 512GB alluring blue 1Tb 2Tb black unibody metal 
|-
| Samsung
|
|
|
| {{N/A|untested}}
|-
| Seagate
|
|
|
| {{N/A|untested}}
|-
| Seagate 
|
|
|
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Toshiba Canvio 1TB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Yes|partition fat32 or sfs to 100GB max - ntfs partitions not detected out of the box - select usb drive in trident prefs and press disable to shutdown}}
|-
| Verbatim 160GB Smartdisk 
| 
| 
|  
| {{yes|works }}
|-
| Western Digital USB 
|
|
|
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;WD Essential 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;WD Passport 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}


=== USB DVD CD ROM Drives ===
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;12.5mm 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;12.5mm enclosure mini-sata dvd-rw 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested needs sole usb3 port to power it}}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;9.5mm enclosure ECD829 mini-sata dvd-rw with Initio Corporation INIC-1618L SATA 
| &lt;!--Vendor ID--&gt;0x13fd
| &lt;!--Product ID--&gt;0x0840
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested but probably needs sole usb3 port to power it}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|}


=== USB to NGFF NVMe SDD HDD DVD CD ROM Drives ===

The older Jmicron JMS539B seems to result in massive filesystem corruption given the amount of corrupted content. Prehaps always avoided Jmicron and opted for Asmedia even if it costed a bit more. Realtek seems to be working okay for me generally speaking and newer Jmicron chipsets are less buggy – but evidently not perfect. 

From [https://goughlui.com/2025/08/17/psa-validate-your-storage-jmicron-jms583-kioxia-bg4-series-ssd-issue/ thread] 

Here is a [https://forums.anandtech.com/threads/stable-nvme-usb-adapter.2572973/ very long thread] that discusses data corruption and stability issues with these bridges. The majority of the posts are complaining of dropouts, hangs and the like, which usually down to either a poor USB 3.x implementation (SuperSpeed connections are very picky as to cables, ports and trace routing) or problematic compatibility. Regardless, the [https://www.legitreviews.com/jmicron-jms583-controller-version-matters-for-portable-usb-drives_219422 JMS583 is known to have several versions] noting that the last revision (C) in that article is a 2021 release which should fix earlier stability and cable quality compatibility issues. 
JMS583-STD-Release-v00.02.01.04-Bus Power.bin is the latest JMS583 firmware as of August 2025. 

Early firmware RTL9210 seems to have issues as well 


* RTL9210B
* JMS583 rev1 with firmware A2 or A3  

* RTL9210A
* JMS583 firmware 2.0.9 
* Asmedia ASM2362

* RTL9201A


The reference Hardware ID for the JMS583 chipset from JMicron is:
VID_152D&amp;PID_0583&amp;REV_0209
where &quot;VID_152D&quot; identifies a JMicron product;
&quot;PID_0583&quot; is the generation chipset;
&quot;REV_0209&quot; is the firmware version installed.

In the same way, the reference Hardware ID for the RTL9210 from Realtek is:
VID_0BDA&amp;PID_9210&amp;REV_3100
&quot;VID_0BDA&quot; is for a Realtek product, &quot;PID_9210&quot; is referred to the chipset and &quot;REV_3100&quot; to the firmware.


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;ASM1153E / ASM1153 with firmware 140509_A1_82_40 or 141126_A1_EE_82. Both supports UASP and TRIM on USB 3.1 Gen.1 adapter
| &lt;!--Vendor ID--&gt;0x174c
| &lt;!--Product ID--&gt;0x55aa
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{maybe|works with sabrent ec-uasp}}
|-
| &lt;!--Description--&gt;ASM235CM Ugreen aluminum bridging the USB3.2 Gen2x1 to Serial ATA host interface 
| &lt;!--Vendor ID--&gt;0x174c
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;TI 9261 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;ASM225
| &lt;!--Vendor ID--&gt;0x174c
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;JMicron JMS578 issues USB 3.1 Gen.1 adapter 
| &lt;!--Vendor ID--&gt;152d
| &lt;!--Product ID--&gt;0578
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;JMicron JMS576 issues USB 3 to usb-c adapter 
| &lt;!--Vendor ID--&gt;152d
| &lt;!--Product ID--&gt;0576
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{maybe|orico}}
|-
| &lt;!--Description--&gt;JMS562 JMicron Technology Corp
| &lt;!--Vendor ID--&gt;152d
| &lt;!--Product ID--&gt;0562
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;JMS561U
| &lt;!--Vendor ID--&gt;0x152d
| &lt;!--Product ID--&gt;0x1561
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{maybe|works with sabrent ec-uasp}}
|-
| &lt;!--Description--&gt;VL716Q4 Orico black meshed aluminum usb c
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Asmedia ASM1053E 
| &lt;!--Vendor ID--&gt;0x1B21 
| &lt;!--Product ID--&gt;0x55aa
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;ASmedia ASM1051E
| &lt;!--Vendor ID--&gt;0x174c
| &lt;!--Product ID--&gt;0x55aa
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Asmedia ASM1053
| &lt;!--Vendor ID--&gt;0x174C
| &lt;!--Product ID--&gt;0x1536
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} 
|-
| &lt;!--Description--&gt;Asmedia ASM104x
| &lt;!--Vendor ID--&gt;0x1B21 
| &lt;!--Product ID--&gt;0x1042 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} 
|-
| &lt;!--Description--&gt;Unknown Chinese version 
| &lt;!--Vendor ID--&gt;0x0bc2
| &lt;!--Product ID--&gt;0x2312 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{maybe|sometimes works}}
|-
| &lt;!--Description--&gt;JMicron N5321 gr
| &lt;!--Vendor ID--&gt;0x152d
| &lt;!--Product ID--&gt;0xa583
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Initio Corp INIC-1618L mini slimline sata 6 + 7 pins to usb2 adapter 
| &lt;!--Vendor ID--&gt;0x13FD
| &lt;!--Product ID--&gt;0x0840
| &lt;!--Revision--&gt;0114
| &lt;!--Opinion--&gt;{{maybe|sometimes works mini sata to usb2 detects 201x laptop DVD as MassStorage(CD/DVD) but may need powered USB hub}}
|-
| &lt;!--Description--&gt;Unknown mini sata to usb3 adaptor 
| &lt;!--Vendor ID--&gt;0x01F75
| &lt;!--Product ID--&gt;0x0621
| &lt;!--Revision--&gt;0036 
| &lt;!--Opinion--&gt;{{maybe|sometimes works mini sata to usb3 detects 201x notebook DVD drive as MassStorage(SCSI) but 5V 1.5Amp needs powered hub to burn }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|}


=== External Floppy ===
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;[http://techtravels.org/amiga/amigablog/ Amiga Floppy Project]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{no|no driver}}
|-
| &lt;!--Description--&gt;[http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=842 Catweasel Mk4]
| 0xE159
| 0x0001
| 0x00
| {{yes|[http://archives.aros-exec.org/index.php?function=browse&amp;cat=driver/storage works]}}
|-
| &lt;!--Description--&gt;[http://hxc2001.free.fr/floppy_drive_emulator/ HxC Floppy Emulator]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{no|no driver}}
|-
| &lt;!--Description--&gt;[http://www.softpres.org/glossary:kryoflux KyroFlux]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{no|no driver}}
|-
| &lt;!--Description--&gt;Samsung SFD-321U/EP USB Floppy
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{no|no driver}} 
|-
| &lt;!--Description--&gt;[http://www.cbmstuff.com/proddetail.php?prod=SCP SuperCard Pro] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;[https://www.facebook.com/groups/greaseweazle Greaseweazle STM hardware], [https://cowlark.com/fluxengine/index.html Greaseweasel support], [https://github.com/keirf/Greaseweazle/wiki software], [https://amigakit.amiga.store/greaseweazle-p-91279.html buy], 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;FL-2501 USB Portable Diskette Drive  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2009 usb - [https://amiga.robsmithdev.co.uk/ Drawbridge] [https://github.com/RobSmithDev/ArduinoFloppyDiskReader software] ribbon cable compat with p/n 19308801-19 and s/n U356244 - model ASM P/N 27l4226 and FRU P/N 05k9283 - 
|-
| &lt;!--Description--&gt;Dell Floppy Drive Module USB External 3.5&quot; - Teac FD-05PUB 1.44mb 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2004 usb 1.1 
|-
| &lt;!--Description--&gt;USB FLOPPY DISK DRIVE (USB External Floppy Disk) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;[https://github.com/SukkoPera/OpenFlops OpenFlops] with [https://github.com/keirf/flashfloppy FlashFloppy] Gotech clone 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;[https://github.com/hmerrett/HenryFlops HenryFlops reworked OpenFlops] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}


==ptp.class (PTP and MTP - other cameras and mp3 players)==

=== Cameras ===
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;Canon EOS 20D
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2004  }}
|-
| &lt;!--Description--&gt;Canon 350D (also known as the Digital Rebel XT/Kiss Digital N) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2005 DIGIC II processor 8-megapixel }}
|-
| &lt;!--Description--&gt;Canon PowerShot A430 A560 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2006 }}
|-
| &lt;!--Description--&gt;Canon EOS 400D (XTi) digital SLR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2007 }}
|-
| &lt;!--Description--&gt;Canon EOS 1000D also known as Rebel XS
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008 10.2mp 720p  }}
|-
| &lt;!--Description--&gt;Canon 450D aka Rebel Xsi 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008 12.2mp }}
|-
| &lt;!--Description--&gt;Canon PowerShot S90 S95 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009 2010 720p video - 10Mpixel }}
|-
| &lt;!--Description--&gt;Canon Powershot SD960 IS Digtal ELPH 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009 Still Image: Exif 2.2 (JPEG), Movie: MOV (Image: H.264; Audio: Linear PCM) Lithium-ion Battery Pack NB-4L }}
|-
| &lt;!--Description--&gt;Canon EOS 500D aka Rebel  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009 1080p 15.1MP Lithium  }}
|-
| &lt;!--Description--&gt;Canon EOS 550D 600D aka Rebel T2i T3i DSLR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2010-2011 1080p 18MP Lithium LP-E8 }}
|-
| &lt;!--Description--&gt;Canon Powershot S100 S110 S120  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011-2013 720p-1080p video 12.1MP and above versions - }}
|-
| &lt;!--Description--&gt;Canon EOS 1100D DSLR Camera aka Rebel T3 SLR, EOS Kiss X50 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011 720p 10Mpixels Lithium  }}
|-
| &lt;!--Description--&gt;Canon EOS 650D 700D aka Rebel T4i T5i T6i SLR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012-2013 1080p 18Mpixels Lithium LP-E8 articulating flip out twistable screen }}
|-
| &lt;!--Description--&gt;Canon ELPH 300 HS (IXUS 220 HS) 230 100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012 blogging camera }}
|-
| &lt;!--Description--&gt;Canon PowerShot N 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2013  12.1 MP CMOS, DIGIC 5 Wifi Lithium Battery Pack NB-9L }}
|-
| &lt;!--Description--&gt;Canon Powershot G7 X, G7X-II 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014-2016 1080p video 12.1MP and above versions - }}
|-
| &lt;!--Description--&gt;Canon EOS 1300D DSLR Camera aka Rebel T6 SLR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2016 1080p 16Mpixels Lithium  }}
|-
| &lt;!--Description--&gt;Canon Powershot G7x G5X 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| G7X flip up and G5X flip out - same batteries - no external microphone input - }}
|-
| &lt;!--Description--&gt;Canon EOS M3 M5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| flip out - same batteries - }}
|-
| &lt;!--Description--&gt;Canon EOS 60D 70D 80D 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Canon 6D 7D 8D 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|untested}}
|-
| &lt;!--Description--&gt;Canon 5D Mark II III IV DSLR
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Canon 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Canon 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Fuji FinePix A850
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;FujiFilm Finepix F100fd
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Fuji FinePix F810
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Fuji xf1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| pocketable exr cmos 12mp }}
|-
| &lt;!--Description--&gt;Fuji xt1  x-t1  x10 x-t10
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 1080p }}
|-
| &lt;!--Description--&gt;Fujifilm x100 x100s x100t 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Fuji xPro1 xPro2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Fuji xt2 / x-t2 x-t20 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 4K video }}
|-
| &lt;!--Description--&gt;Fuji 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Fuji 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|untested}}
|-
| &lt;!--Description--&gt;Fuji 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|untested}}
|-
| &lt;!--Description--&gt;GoPro HERO 3 HERO4 HERO 5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Nikon 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Nikon D100, D60
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2004 Compact flash storage - non interchangeable lenses up to 12.3MP sensor }}
|-
| &lt;!--Description--&gt;Nikon D50, D50x 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2005  storage - 6.1MP sensor }}
|-
| &lt;!--Description--&gt;Nikon D70, D80, D90 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2006 Compact flash storage - 10MP sensor }}
|-
| &lt;!--Description--&gt;Nikon D40, D40x 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2007  storage -  10MP sensor }}
|-
| &lt;!--Description--&gt;Nikon D300, D700
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008  storage -  12.3MP sensor }}
|-
| &lt;!--Description--&gt;Nikon D2Xs, D2Hs, D3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2006-2008  storage - sensor }}
|-
| &lt;!--Description--&gt;Nikon D3000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008 720p video }}
|-
| &lt;!--Description--&gt;Nikon D5000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2010 720p video unlike D3000 }}
|-
| &lt;!--Description--&gt;Nikon D6000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2010 16mpixel}}
|-
| &lt;!--Description--&gt;Nikon D7000  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2010 16.2mp 720p video }}
|-
| &lt;!--Description--&gt;Nikon L26 L27 L28 L29 L31 Coolpix compact cameras 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011 720p video - 2 AA - pocket sized }}
|-
| &lt;!--Description--&gt;Nikon D3100   
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011 720p video 14.2mp}}
|-
| &lt;!--Description--&gt;Nikon D5100 DSLR
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011 16.2mp  720p}}
|-
| &lt;!--Description--&gt;Nikon L810 L820 L830 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012-2014 720p video }}
|-
| &lt;!--Description--&gt;Nikon D4 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012  storage - sensor }}
|-
| &lt;!--Description--&gt;Nikon D7100 D7200  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012-2014 up to 24.2mp 1080p video }}
|-
| &lt;!--Description--&gt;Nikon D3200  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012 1080p 24MPixel}}
|-
| &lt;!--Description--&gt;Nikon D5200 D5300  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2013 24.1MP 1080p }}
|-
| &lt;!--Description--&gt;Nikon D800 D600 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014 1080p video sd card storage - dust/oil issue at start}}
|-
| &lt;!--Description--&gt;Nikon D3300 DSLR
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014 24.2MP 1080p  }}
|-
| &lt;!--Description--&gt;Nikon D500, a high-performance DX-format (APS-C) DSLR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2016 }}
|-
| &lt;!--Description--&gt;Nikon D3400 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2016 24.2MP 1080p }}
|-
| &lt;!--Description--&gt;Nikon D5500 D5600 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2016-2018 24.1MP 1080p }}
|-
| &lt;!--Description--&gt;Nikon D810 D610 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 1080p video sd card storage }}
|-
| &lt;!--Description--&gt;Nikon D7300 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 4K UHD video }}
|-
| &lt;!--Description--&gt;Nikon D900 D850 D820 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 4k 46MP }}
|-
| &lt;!--Description--&gt;Nikon 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Nikon 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Olympus C-370 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2004 3.2mp }}
|- 
| &lt;!--Description--&gt;Olympus Camedia C-725 Ultrazoom
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2004 3mp aa batteries, }}
|-
| &lt;!--Description--&gt;Olympus Evolt E-500
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2005 8mp  }}
|- 
| &lt;!--Description--&gt;Olympus 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Olympus Evolt E-410 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2007  }}
|- 
| &lt;!--Description--&gt;Olympus Evolt E-510
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2007 10MP Live MOS sensor with TruePic III processor,  }}
|-
| &lt;!--Description--&gt;Olympus E-420
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008 10mp, compactflash and xD cards,  }}
|-
| &lt;!--Description--&gt;Olympus E-520
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008 10mp, compactflash and xD cards,  }}
|- 
| &lt;!--Description--&gt;Olympus E-620
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009 12.3mp, compactflash, xD and microdrive cards,  }}
|- 
| &lt;!--Description--&gt;Olympus E-30 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009  }}
|- 
| &lt;!--Description--&gt;Olympus E-450 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009 10mp,  }}
|- 
| &lt;!--Description--&gt;Olympus 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- 
| &lt;!--Description--&gt;Olympus 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- 
| &lt;!--Description--&gt;Pentax * ist DS DSLR camera
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2005 6.1mp  }}
|- 
| &lt;!--Description--&gt;Pentax K10D
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2006 10.2mp APS-C CCD no video and older manual Pentax K-mount lenses}}
|-
| &lt;!--Description--&gt;Pentax K20D
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2008 14.6MP APS-C but no video recording mode }}
|-
| &lt;!--Description--&gt;Pentax K30 K-5 II 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2012 16MP full HD (1080p) recording at 24/25/30 fps}}
|-
| &lt;!--Description--&gt;Pentax K-3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014 24MP 1080p  }}
|-
| &lt;!--Description--&gt;Pentax K-3 II
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2015 24MP  }}
|-
| &lt;!--Description--&gt;Pentax K-3 III
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 25.7MP BSI CMOS sensor  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Panasonic Lumix LZ10 LZ20 DMC-LZ30 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 720p video }}
|-
| &lt;!--Description--&gt;Panasonic TZ1 TZ5  TZ9 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Panasonic Lumix GH1 GH2 like the DMC-GH2HEB-K - GH3 DMC-GH3HEB-K 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| Four Thirds (GH2)  MFT Micro Four Thirds (GH3) limited to 29mins recording }}
|-
| &lt;!--Description--&gt;Panasonic AF series AF100 AF101 AF102 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Panasonic Lumix DMC-G2 DMC-G3 G5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Panasonic TZ60 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Panasonic DMC LX7 10 LX15 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Panasonic GF7 GX8 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Panasonic G80 G85 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| micro 4/3 }}
|-
| &lt;!--Description--&gt;Panasonic GH4 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| micro 4/3 - shooting in MOV or MP4 formats recording limited to sd card size but split files because the FAT32 file system only supports files up 4GB in size, which amounts to around 5 minutes of 4K (100mbps) footage - GH4 appears to create 4GB files as a rule, regardless of whether the memory card’s file system supports larger files or not - }}
|-
| &lt;!--Description--&gt;Panasonic GH5 gx80 gx85 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| Effective: 20.3 Megapixel 5184 x 3888 - 2 sd card slots compatible with high-speed, high capacity UHS-II - sd card v rating like the v90 should record at 60MB/s to be compatible with the GH5 in the All-I format - possible file corruption with .mdt files - new firmware 2.0 update, the Panasonic GH5 becomes the first 5K - }}
|-
| &lt;!--Description--&gt;Panasonic FZ2000 FZ2500 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Panasonic 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Samsung 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Samsung WB100 WB1100 WB150 WB2200 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 16MP }}
|-
| &lt;!--Description--&gt;Samsung NX11 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Samsung  NX200, NX20, NX1000 and NX210
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 20.3Mp APS-C sized CMOS image sensor }}
|-
| &lt;!--Description--&gt;Samsung 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Samsung 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Sanyo Xacti CG65
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Sanyo 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Sony Alpha DSLR-A100
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2005 6.1MP }}
|-
| &lt;!--Description--&gt;Sony Cyber-shot DSC camera models W110 W220 H300 H400 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2007 }}
|-
| &lt;!--Description--&gt;Sony Alpha DSLR-A200
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008 10.2MP }}
|-
| &lt;!--Description--&gt;Sony Alpha DSLR-A230
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009 10.2MP }}
|-
| &lt;!--Description--&gt;Sony A290 DSLR Camera 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2010 14.2MP }}
|-
| &lt;!--Description--&gt;Sony Cybershot HX20V HX30V 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011 18mp 720p  - steady shot unit / optical block can cause buzzing noise and/or jumping image in lcd / viewfinder - dots are dirt and this voids the warranty }} 
|-
| &lt;!--Description--&gt;Sony Cybershot HX50V HX60V 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012 20.2MP 1080p  - steady shot unit / optical block can cause buzzing noise and/or jumping image in lcd / viewfinder - dots are dirt and this voids the warranty }} 
|-
| &lt;!--Description--&gt;Sony A77 A99 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012 }}
|-
| &lt;!--Description--&gt;Sony WX100 WX150 wx220 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012 2014 }}
|-
| &lt;!--Description--&gt;Sony NEX-6 Sony NEX-7 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011 16 to 24MP }}
|-
| &lt;!--Description--&gt;Sony NEX-3N Sony NEX-5N 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2013 16MP }}
|-
| &lt;!--Description--&gt;Sony α58 Sony α68 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2013 20.1 MP  2014 24mp }}
|-
| &lt;!--Description--&gt;Sony rx100 mk III 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014 20.1MP 1.0-type back-illuminated Exmor R CMOS sensor, often after boot-up, the motor starts running for no reason for first versions' -  }}
|-
| &lt;!--Description--&gt;Sony α5000 a5000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014 20.1 Megapixel APS-C Exmor APS HD CMOS 1080p Sony E-mount [https://github.com/ma1co/Sony-PMCA-RE hack] using [https://www.youtube.com/watch?v=8M4hR9HiOzM this] }}
|-
| &lt;!--Description--&gt;Sony α6000 a6000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014 24MP APS-C sensor }}
|-
| &lt;!--Description--&gt;Sony α7 A7S a7r a7c 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014 mirror less - more compact }}
|-
| &lt;!--Description--&gt;Sony α77 II, α99 II, 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2015 24.3 MP,  2016 42.4mp   }}
|-
| &lt;!--Description--&gt;Sony rx100 mk IV V 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2015 2016 }}
|-
| &lt;!--Description--&gt;Sony RX0 RX zero, RX0 II
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2015 2017 }}
|-
| &lt;!--Description--&gt;Sony α6500 a6500 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2016 24.2MP APS-C sensor 4K }}
|-
| &lt;!--Description--&gt;Sony α7 Alpha 7 II E-mount interchangeable lens mirrorless camera 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2017 24.2mp,  }}
|-
| &lt;!--Description--&gt;Sony α7 A7Sii a7r a7c 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 mirror less - more compact }}
|-
| &lt;!--Description--&gt;Sony a7 III α77 ILCE7M3/B Full-Frame Mirrorless Interchangeable-Lens Camera
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 24.2mp,  }}
|-
| &lt;!--Description--&gt;Sony ZV-1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 24mm optical zoom, }}
|-
| &lt;!--Description--&gt;Sony ZV-1F
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 entry-level vlogging, 1-inch 20.1MP, ultra-wide 20mm f/2 prime lens}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|}

&lt;pre &gt;
Lens Mounts

Canon EF EF-S
Nikon F 
Panasonic 
Olympus OM 
Pentax DA, FA, F, A, M, and K series
Fujifilm X mount 
&lt;/pre &gt;

&lt;pre &gt;
Sensors

APS-C 
S35 
Full Frame 
43 Four Thirds 
M43 MFT Micro four thirds 
&lt;/pre &gt;


=== Digital Voice Recorder Dictaphone Dictation Machine Handheld ===
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Olympus VN-7000
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested 2011 }}
|-
| &lt;!--Description--&gt;Olympus VN-7200
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|untested 2012 no usb }}
|-
| &lt;!--Description--&gt;Olympus VN-7500 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested 2012 }}
|-
| &lt;!--Description--&gt;Olympus VN-7600 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested 2013 }}
|-
| &lt;!--Description--&gt;Olympus WS-100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested usb}}
|-
| &lt;!--Description--&gt;Olympus VN-7700 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Olympus VN-8600 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Olympus VN-711PC
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Olympus VN-712PC
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Olympus VN-731PC 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Olympus 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Olympus WS-811
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested slide out usb-a - aaa battery - ok recordings }}
|-
| &lt;!--Description--&gt;Olympus VN-540PC Olympus VN-541PC 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Philips DVT1250
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Sony 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Sony 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Sony 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Sony ICD-UX470
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Sony ICD-UX560
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Sony ICD-UX570 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
|}


=== USB eBooks Readers drm free EPUB version 2.0.1 (2007), 3.0 (2011), 3.1 (2015) or [https://www.w3.org/TR/epub-33/ 3.3 (2024)] [https://github.com/thansen0/sample-epub-minimal epub examples] formats access ===

EPUB file format is an open standard based on XHTML for content and XML for metadata, contained in a zip file archive 

PDF v2.0 in 2017, 2009 takeover by ISO Org, 1.7 in 2006 , 1.6 in 2005, 1.4 in 2001, 1.3 in 1999, 1.0 in 1993 


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;15%&quot; |Access
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Barnes and Noble Nook Simple Touch NST BNRV300 
| &lt;!--Vendor ID--&gt;0x2080
| &lt;!--Product ID--&gt;0x0003
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;when finding the right micro usb cable that works, internal nook memory not accessible but sd card fat32 readable and writable outside 
| &lt;!--Opinion--&gt;{{N/A|2011 6in 600x800 e-ink 16 grayscale .jpg}} battery remove sd card and Torx T5 back top for Cameron Sino CS-BNR003SL - USA 1.2.2 md5sum 351e26527e80156183e74be2da2ce89f *nook_1_2_update.zip - 1.2.1 UK fdba3981f7f221cc5143db6329645bc2 *nook_1_2_update.zip - skip registration, Turn on the device, but do NOT start setting it up. Hold down the top right button on the front of the device and slide your finger from left to right across the top of the E Ink screen. A ‘Factory’ button should appear in the top left corner of the screen. Press it. Once in the Factory menu, hold down the top right button on the front of the device and tap the bottom right corner of the screen should now see a ‘Skip Oobe’ button. Tap that and the Nook should finally load the home screen. Poor battery management - 
|-
| &lt;!--Description--&gt;Barnes and Noble Nook Simple Touch with Glowlight 
*2012 Nook Simple Touch with GlowLight BNRV350 
*2013 Nook GlowLight BNRV500
| &lt;!--Vendor ID--&gt;0x2080
| &lt;!--Product ID--&gt;0x0004 0x0007 
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|2012 untested }} perform a hard reset: Turn off the nook completely, turn it on, as soon as you see the screen flash begin holding the bottom page turn buttons until the screen flashes with a message asking reset, press the 'n' key twice to start the reset - Poor battery management - 
|-
| &lt;!--Description--&gt;Nook Glowlight 4 Plus 7.8-inch screen 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} Poor battery management - 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
*NOOK 1st Edition (2009-2018) BNRZ100
*NOOK Color (2010-2024) BNRV200
*NOOK Tablet (8GB/16GB) (2011-2024) BNTV250A / BNTV250
*NOOK HD (2012-2024) BNTV400 
*NOOK HD+ (2012-2024) BNTV600 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Elonex 511EB 
| &lt;!--Vendor ID--&gt;045e:ffff
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|2009 untested Preferences-&gt;advanced-&gt;debug device detection}}
|-
| &lt;!--Description--&gt;[https://jaforeck.wordpress.com/2012/08/05/ready-to-meet-viktor-navorski-gained-access-to-elonex-621ebs-terminal-52/ Elonex 621EB] eBook 
| &lt;!--Vendor ID--&gt;0x1f85
| &lt;!--Product ID--&gt;0x1688
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;unlocked ootb 
| &lt;!--Opinion--&gt;{{N/A|2010 untested usb mini charging 6&quot; diagonal eInk Screen - 800 x 600 pixels, 8 Level 166dpi Paperlike screen, Embedded 1GB Flash NAND, full SD Card Slot up to 16GB - WAV, MP3, JPG, PNG, BMP, GIF support and ePub and PDF(with reflow) (TXT, HTML) support}}
|-
| &lt;!--Description--&gt;Elonex 700eb 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|2011 untested adjust screen blanking by menu then settings then device standby, you can then turn it off}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;iRiver Story HD eBook 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }} freescale imx.508 arm mcimx508cvkbb cpu with 2gb samsung nand, m13892aj charging chip, eb07_main_mp1_110321 mobo, mini usb, atheros ar61026 wifi - 
|-
| &lt;!--Description--&gt;iRiver Story 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Kobo Rakuten Touch A/B	kobo3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Kobo Touch C, Kobo Mini, Kobo Glo N613, Kobo Aura HD N514 N204	kobo4
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Kobo Aura, Kobo Aura H2O, kobo5
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|2013 6in untested }}
|-
| &lt;!--Description--&gt;Kobo Aura H2O Edition 2 v1, Kobo Glo HD, Kobo Touch 2.0, Kobo Aura ONE N709, Kobo Aura ONE Limited Edition, Kobo Aura Edition 2 v1 N236,	kobo6 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Kobo Aura H2O Edition 2 v2, Kobo Aura Edition 2 v2, Kobo Nia, Kobo Clara HD, Kobo Forma, Kobo Libra H2O	kobo7
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Kobo Elipsa, Kobo Sage	kobo8
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
*Kobo Libra 2  kobo9, Kobo Clara 2E	kobo10, Kobo Elipsa 2E	kobo11
*Kobo Libra Colour	kobo13, Kobo Clara BW, Kobo Clara Colour	kobo12
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Pandigital Personal eReader aka? Papyre 6.2 very similar to BQ Avant Firmware
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2011  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Sony PRS 300 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Sony PRS 350 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|2009 epub bbeb cbz untested }}
|-
| &lt;!--Description--&gt;Sony PRS-650
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Kindle K1 D00111 - Main Menu=: Settings: Menu=: Device Info shows S/N 
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x0002
| &lt;!--Revision--&gt;100
| &lt;!--Access--&gt;256mb 
| &lt;!--Opinion--&gt;{{N/A|2007 untested Marvell Xscale PXA255}}
|-
| &lt;!--Description--&gt;Kindle K2, D00511 170-1012-00, D00701 D00801 S11S01B  
* k2 means K2 US
* k2i means K2 GW
* dx means KDX US
* dxi means KDX GW
* dxg means KDX Graphite 
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x0003
| &lt;!--Revision--&gt;100
| &lt;!--Access--&gt;2gb unless jb 
| &lt;!--Opinion--&gt;{{N/A|2010 untested Freescale i.MX31 }} the Kindle is a small computer running Linux 2.6 on an ARM processor
|-
| &lt;!--Description--&gt;AMAZON Kindle D00901 3rd Gen with keyboard - Menu, Settings for S/N and then Menu again to choose Update 
* S/N starts B006 means k3g aka K3 3G US 
* S/N starts B008 means k3w aka K3 WiFi 
* S/N starts B00A means k3gb aka K3 3G UK EU 
 - debug mode with ;debugON and ~help
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x0004
| &lt;!--Revision--&gt;100
| &lt;!--Access--&gt;{{yes|4Gb internal no access until jailbroken JB}} 
| &lt;!--Opinion--&gt;2010 with mobi and azw3 formats only - micro usb 5v 0.85a - freescale i.mx35 ARM soc with 12bit parallel interface with epson e-ink cpu, 256MB synchronous dynamic RAM, 4GB eMMC internal memory only but no sd slot, MC13892 PMIC - atheros wifi 54mbit pci-e a e keyed wifi - ?? later models wm96103 audio codec - display has 2Mbit serial memory ic on ribbon cable with 4bpp inverse grayscale display not touchscreen - 3g module - screen replacement really annoying - 4 test points near T07 = TX RX GND ? - as of 2025, JB v0.13.N, MKK2014, MKK2025, KUAL, KoReader Legacy2025, and maybe later SS v0.47.N, Python 0.14.N, Fonts v5.16.N, USBNet v0.57.N - USB-downloader mode when Vol+ is pressed during startup - Shift + Alt + M for Minesweeper - 
|-
| &lt;!--Description--&gt;Amazon Kindle 4th Generation k4 D01100 two buttons, square movement and two buttons at bottom 
*B00E 
plastic back clipped in [https://www.youtube.com/watch?v=LV1dyNkjjro many places] and strongly taped down to battery cover 
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x0005
| &lt;!--Revision--&gt;100
| &lt;!--Access--&gt;2gb unless jb with USB MS, USBMS aka also known as USB MSC or UMS
| &lt;!--Opinion--&gt;{{unk|2012 once back off use Torx T5 to remove battery cover screws - battery glued down S2011-001-A 515-1058-01 DR-A015 MC-265360 - Freescale i.MX508 SOC, 2Gb eMMC storage, 256MiB of LPDDR1, MC13892 PMIC - vendor modified u-boot imximage based on u-boot v2009.08 - USB-downloader mode press the fiveway down button during startup resetmykindle - as of 2025 upgrade firmware from 4.1.x and to 4.1.4, sign into account and copy jb.1.8 bits, mkk-2014, mkk-2025, kual and then uninstall kual, koreader2025 - }}
|-
| &lt;!--Description--&gt;Kindle Touch WiFi (Kindle 5th Gen) D01200 K5, KT
*Once signed into an Amazon Account get S/N under Settings -&gt; Device Options
*B00F 	Kindle Touch 3G + WiFi (Kindle 5) (U.S. and Canada) [Mostly]
*B011 	Kindle Touch WiFi (Kindle 5)
*B010 	Kindle Touch 3G + WiFi (Kindle 5) (Europe) 
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x0006
| &lt;!--Revision--&gt;100
| &lt;!--Access--&gt;4gb unless jb 
| &lt;!--Opinion--&gt;{{unk|2013 touchscreen i.MX508 SOC, 256MiB of LPDDR1 and USB-downloader mode by the SOC microcode when a specific key is pressed during startup: the home button on model D01200 - update firmware 5.3.2 to 5.3.7.3, access account, }} 
|-
| &lt;!--Description--&gt;Kindle PaperWhite 3G + WiFi (U.S.) [Mostly] PW 
&lt;pre&gt;
B024 	Kindle PaperWhite WiFi 
B01B 	Kindle PaperWhite 3G + WiFi (U.S.) [Mostly]
B020 	Kindle PaperWhite 3G + WiFi (Brazil) 
B01C 	Kindle PaperWhite 3G + WiFi (Canada)
B01D 	Kindle PaperWhite 3G + WiFi (Europe)
B01F 	Kindle PaperWhite 3G + WiFi (Japan)
&lt;/pre&gt;
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x0007
| &lt;!--Revision--&gt;100
| &lt;!--Access--&gt;2gb 
| &lt;!--Opinion--&gt;{{unk|2013 Freescale i.MX508 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x0008
| &lt;!--Revision--&gt;100
| &lt;!--Access--&gt;2gb 
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Kindle PaperWhite 2 (2013) PW2 
*B0D4, 90D4 WiFi (U.S., Intl.) 
*B05A, 905A WiFi (Japan)
*B0D5, 90D5 3G + WiFi (U.S.) [Mostly]
*B0D6, 90D6 3G + WiFi (Canada] 
*B0D7, 90D7 3G + WiFi (Europe)
*B0D8, 90D8 3G + WiFi (Russia)
*B0F2, 90F2 3G + WiFi (Japan)
*B017, 9017 WiFi (4GB) (U.S., Intl.)
*B060, 9060 3G + WiFi (4GB) (Europe)
*B062, 9062 3G + WiFi (4GB) (U.S.) [Mostly]
*B05F, 905F 3G + WiFi (4GB) (Canada)
*B061, 9061 3G + WiFi (4GB) (Brazil) 
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x0009
| &lt;!--Revision--&gt;100
| &lt;!--Access--&gt;2gb or 4gb 
| &lt;!--Opinion--&gt;{{unk| PW2 uses Freescale/NXP i.MX6 SoloLite  }}
|-
| &lt;!--Description--&gt;Kindle Paperwhite 3 PW3 i.e. Kindle 7th gen 
*G090G1 (2015) WiFi 
*G090G2 (2015) 3G + WiFi (U.S.) [Mostly] 
*G090G4 (2015) 3G + WiFi (Mexico)
*G090G5 (2015) 3G + WiFi (Europe, Australia) 
*G090G6 (2015) 3G + WiFi (Canada)
*G090G7 (2015) 3G + WiFi (Japan) 
*G090KB (2015) WiFi 
*G090KC (2015) 3G + WiFi (Japan) 
*G090KE (2016) 3G + WiFi (International) White 
*G090KF (2016) 3G + WiFi (International) White 
*G090LK (2016) WiFi, 32GB (Japan) 
*G090LL (2016) WiFi, 32GB (Japan) White 
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x000A
| &lt;!--Revision--&gt;100
| &lt;!--Access--&gt;4gb 
| &lt;!--Opinion--&gt;{{unk| ease up glued down front bezel rim panel gently, remove 11 screws underneath and lift screen up from bottom end - battery underneath -  }}
|-
| &lt;!--Description--&gt;Kindle PaperWhite 4 (2018) PW4
*G000PP, G8S0PP WiFi, 8GB
*G000T6, G8S0T6 WiFi, 32GB
*G000T1  WiFi+4G, 32GB
*G000T2  WiFi+4G, 32GB (Europe)
*G00102  WiFi, 8GB (India)
*G000T3  WiFi+4G, 32GB (Japan)
*G0016T, G8S16T WiFi, 8GB Twilight Blue
*G0016Q, G8S16Q WiFi, 32GB Twilight Blue
*G0016U  WiFi, 8GB Plum
*G0016V, G8S16V WiFi, 8GB Sage 
*G00103  WiFi, 32GB (India) 
*G0016R  WiFi, 32GB Plum
*G0016S  WiFi, 32GB Sage 
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x000B
| &lt;!--Revision--&gt;100
| &lt;!--Access--&gt;8gb or 32gb
| &lt;!--Opinion--&gt;{{unk| Freescale/NXP i.MX6 SoloLite }}
|-
| &lt;!--Description--&gt;Kindle Oasis 2 and 3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;8gb or 32gb
| &lt;!--Opinion--&gt;{{unk| NXP i.MX7D  }}
|-
| &lt;!--Description--&gt;Kindle Paperwhite 5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;8gb or 16gb
| &lt;!--Opinion--&gt;{{unk| MediaTek MT8110  }}
|-
| &lt;!--Description--&gt;Kindle 11 Scribe 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;8gb or 16gb
| &lt;!--Opinion--&gt;{{unk| MediaTek MT8113 }}
|-
| &lt;!--Description--&gt;Kindle Paperwhite 6 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;16gb or 32gb
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Kindle Paperwhite Gen 11 and 12 - Signature 
| &lt;!--Vendor ID--&gt;0x1949
| &lt;!--Product ID--&gt;0x0
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;16Gb or 32Gb 
| &lt;!--Opinion--&gt;{{unk|2024 account not blocked,  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;[https://github.com/Modos-Labs Modos Labs] open source e-ink 60Hz 75Hz caster controller and glider monitor 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Xteink X3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;[https://www.xteink.com Xteink X4] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;2025 4.3in 220ppi no touchscreen so [https://www.youtube.com/watch?v=R7RuokaVauo buttons navigation] - 650mAh battery - micro-sd slot up to 512Gb covering epub, txt, and jpg in directories with [https://github.com/crosspoint-reader crosspoint reader] esp32 cpu custom rom firmware using [https://xteink.dve.al/ Flash website] on usb-c but no ecosystem store 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|}


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;15%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;15%&quot; |Access
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;Amazon D01400 Kindle Fire (1st Generation) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{No|2010 too old }} android 2.3 and touchscreen digitizer fails often, battery SWE P/N 1002000004742 Model KC1 (EU) QP01 (US) 16.28whr, ti 257epl9l omap 4430 with elpida 88164b3pf-10-f88164b3pf or hynix,  mobo ??,, DAOKC1MB8F0 Rev F, ti aic3110 audio codec, 
|-
| &lt;!--Description--&gt;Amazon Fire 7in X43260 X43Z60 2nd Gen 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2012 untested FireOS Android 4 omap 4460 and PowerVR SGX540}}
|-
| &lt;!--Description--&gt;Amazon Kindle Fire HD (3rd Gen) P48WVB4 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2013 untested }}
|-
| &lt;!--Description--&gt;Amazon 
*Amazon Fire HD10 (2015) 
*Amazon Fire HD8 (2015)	
*Amazon Fire HD7 (2015)	(5th Generation) 7 inch 8GB SV98LN 
*Amazon Fire HD7 (2014)	
*Amazon Fire HD6 (2014) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|untested android 5.1 max}}
|-
| &lt;!--Description--&gt;
*Amazon Fire 10 (2017) 
*Amazon Fire 8 (2017) 7th Gen 8 inch SX034OT 
*Amazon Fire 7 (2017) (7th Generation) 7 inch 16GB (SR043KL) 
*Amazon Kindle Fire 7 (7th Generation) 7 inch 8GB WIFI Tablet (SR043KL) 
*Amazon Fire HD8 (2016)	
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| Android 5.1 max 7in screen resolution of 1024 x 600, }}
|-
| &lt;!--Description--&gt;
*Amazon Fire 10/10+ (2021) 
*Amazon Fire 8/8+ (2020) 
*Amazon Fire 10 (2019) 
*Amazon Fire 7 (2019) 
*Amazon Kindle Fire 7 9th Gen 16GB M8S26G 
*Amazon Fire 8 (2018) 8th Gen 8 inch 32GB L5S83A 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| android 9 max}}
|-
| &lt;!--Description--&gt;Amazon 
*Amazon Fire HD 10 (2023)	
*Amazon Fire Max 11 (2023)	
*Amazon Fire 8 (2022)	
*Amazon Fire 7 (2022)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| android 11 max}}
|-
| &lt;!--Description--&gt;Amazon Kindle Scribe 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2025  }}
|-
| &lt;!--Description--&gt;Amazon 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Minimal Phone, Mudita Kompakt 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| eink }}
|-
| &lt;!--Description--&gt;Bigme B751C 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|2022 android untested }}
|-
| &lt;!--Description--&gt;Bigme B7 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2025  }}
|-
| &lt;!--Description--&gt;Bigme B6
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 android based color eink small - 300dpi b/w 150ppi color -}}
|-
| &lt;!--Description--&gt;Bigme 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| e-ink }}
|-
| &lt;!--Description--&gt;Bigme Hibreak Pro, Hisense A9
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| e-ink}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;iFlyTech AINote 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 }}
|-
| &lt;!--Description--&gt;iFlyTech AINote 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Meebook 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Onyx Boox Page Palma 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2016 android untested }}
|-
| &lt;!--Description--&gt;Onyx Boox Leaf3C
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Onyx Boox Go Color 7 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2023 untested 7in e-ink e-reader android tablet }}
|-
| &lt;!--Description--&gt;Onyx BooxTab Ultra X C 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Onyx Boox Note Max Air4 C 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Onyx Boox Leaf5C
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Onyx Boox Poke6S 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Onyx Boox Go 10.3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Onyx Boox MC 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| color e-ink 13.3in }}
|-
| &lt;!--Description--&gt;Onyx Boox Go 10.3 (Gen 2) Lumi 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 b/w eink with front light, no EMR annd capacitance pen,  }}
|-
| &lt;!--Description--&gt;Onyx Moaan Pantone 6 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;reMarkable 1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|2021 untested but subscriptions needed for some features }}
|-
| &lt;!--Description--&gt;reMarkable 2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|2023 untested but subscriptions needed for some features }}
|-
| &lt;!--Description--&gt;reMarkable Paper Pro Move 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{N/A|2024 untested but subscriptions needed for some features }}
|-
| &lt;!--Description--&gt;reMarkable 3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 untested but subscriptions needed for some features}}
|-
| &lt;!--Description--&gt;reMarkable 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Supernote A5 X2 Manta
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 }}
|-
| &lt;!--Description--&gt;Supernote A6 X2 Nomad 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk|2023  }}
|-
| &lt;!--Description--&gt;Supernote 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Tolino Vision 2 3 4 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Tolino Epos2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Viwoods AI Paper and AI Paper Mini 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Access--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|}


==printer.class - PostScript 3 and internal ghostscript drivers==


As the only printer driver that AROS supports natively is Postscript, our focus is on applications that generally output postscript formatted data for printing purposes and since the general Joe Public finds postscript capable printer very expensive, postscript interpreters (eg ghostscript) have been developed aas a cheaper option which sit in between postscript data streams and non postscript (HP PCL?) printers.

Set up Printer Prefs for Postscript and set the print to file option.


Ghostscript has internal printer drivers

 gs -h

and with something like

 gs -sDEVICE=stcolor -r300 -sOutputFile=RAM:tempfile gs813:examples/tiger.ps
 copytopar ram:tempfile

It checks if in RAM: exists a outputfile (Cinnamon can export to PS postscript) then it sends this via copytopar to the printer. There was only support for parport (parallel) but Terminillis added support for USB and ethernet. A big issue with using ghostscript for drivers is that data has to originate as postscript (.PS) file.

 gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=RAM:tempfile RAM:file.pdf

the ljet4 output device generates PCL

also the pxlmono driver, which generates more generic PXL (PCL 6)

 gs -q -sstdout=%stderr -sDEVICE=pswrite -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER testpage-a4.ps &gt; test.pdf

 gs -q -sstdout=%stderr -sDEVICE=pxlmono -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER test.pdf &gt; test.pxl


Printers supported by ghostscript...Explanation [http://freebooks.by.ru/view/RedHatLinux6Unleashed/rhl6u151.htm here] or [http://www.gnu.org/software/ghostscript/devices.html here] and [http://pages.cs.wisc.edu/~ghost/doc/printer.htm here]

&lt;pre&gt;
bit            cljet5          ljet4d          pjxl300         pxlcolor
bitcmyk        cljet5c         ljetplus        pkm             pxlmono
bitrgb         deskjet         nullpage        pkmraw          stp
bj10e          djet500         pbm             pksm            tiff12nc
bj200          epswrite        pbmraw          pksmraw         tiff24nc
bjc600         faxg3           pcx16           png16           tiffcrle
bjc800         faxg32d         pcx24b          png16m          tiffg3
bmp16          faxg4           pcx256          png256          tiffg32d
bmp16m         ijs             pcxcmyk         pnggray         tiffg4
bmp256         jpeg            pcxgray         pngmono         tifflzw
bmp32b         jpeggray        pcxmono         pnm             tiffpack
bmpgray        laserjet        pdfwrite        pnmraw          uniprint
bmpmono        lj5gray         pgm             ppm             x11
bmpsep1        lj5mono         pgmraw          ppmraw          x11alpha
bmpsep8        ljet2p          pgnm            psgray          x11cmyk
cdeskjet       ljet3           pgnmraw         psmono          x11gray2
cdj550         ljet3d          pj              psrgb           x11gray4
cdjcolor       ljet4           pjxl            pswrite         x11mono
cdjmono
&lt;/pre&gt;

=== Internal Ghostscript support ===

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;10%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;10%&quot; |Postscript Support
! width=&quot;10%&quot; |GutenPrint Support
! width=&quot;20%&quot; |Hardware Issues 
! width=&quot;10%&quot; |Running Costs 
! width=&quot;20%&quot; |Opinion
|-
| Canon BJ10e
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested with Ghostscript drivers }}
|-
| Canon BJ200
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested with Ghostscript drivers }}
|-
| Epson Stylus Color 600 parport inkjet
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{yes|works - internal ghostscript support}}
|-
| &lt;!--Description--&gt;HP Deskjet 500 Parallel Port 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Postscript Support
| GutenPrint Support
| Hardware Issues 
| Running Costs 
| Opinion 
|-
| HP1220C/PS USB Inkjet
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{yes|works - PS3 emulation only}}
|-
| HP 1700PS USB Inkjet
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{yes|works - PS3 emulation only}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Postscript Support
| GutenPrint Support
| Hardware Issues 
| Running Costs 
| Opinion 
|-
| &lt;!--Description--&gt;LJ-III
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested HP PostScript Cartridge Plus (C2089A) a.. Press &lt;ON LINE&gt; (and take machine off line)
b.. Press &lt;Plus &amp; Minus&gt;, and while holding, press &lt;ALT&gt; and &lt;RESET&gt; together and watch the LCD and let go when the desired mode is displayed.}} 
|-
| &lt;!--Description--&gt;HP Laserjet 4 4M 4MP (1992)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested PS2 emulation HP 4 with optional ps cartridge - HP 4M and 4M+ built in}} 
|-
| &lt;!--Description--&gt;HP Laserjet 4L Parport 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{no|PCL5 HP 4L only - no postscript}} 
|-
| &lt;!--Description--&gt;HP Laserjet 5M (1995) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;PS2 emulation
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested you can try the ljet4 for the various lj5 drivers which produce various flavours of PCL. The 4, 4+ and 5 only really had one issue that plagued them, and it's hardly an issue at all. You would get accordian jams at the exit. A lot of people worked through this by pulling the sheet out before it got caught. Easily fixed by opening back door and scrubbing grime off of rubber rollers. }}
|-
| HP Laserjet 5L Parport (1997) (C3906A bk) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;{{N/A}}
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{no|PCL5 support only.}}
|-
| HP Laserjet 5P 6P (1995) (C3906A bk) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested HP 5p, 6p - Less tiny, slightly less slow. They are pretty bullet proof for low volume best to get postscript module though }}
|-
| HP Laserjet 2100 2100N 2100TN (1999) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested PS2 emulation }}
|-
| HP Laserjet 4000 Series Parport (1998) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|PS3 emulation only (4200 and 4600 have issues)}}
|-
| HP Laserjet 4050 Parport (1999) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;PS3 emulation only
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{maybe|works }}
|-
| HP Laserjet 5000 Parallel Port 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;PS3 emulation only
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|}}
|-
| HP LaserJet 6M, 1200, 1300, 2100, 2200, P2050 (and P2055) P3005, M3025, M3027, 3050, 3300, 4000, 4050, 4100, 4200, 4300, M4345, P3005, P3015, P4010, P4410, M5025, M5035, 5100, 5200, 8000, 8100, or 9000 series 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;PS3 emulation optional only
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{untested }}
|-
| &lt;!--Description--&gt;HP Color LaserJet 2550, 3700, 4650, 8500 and 8550 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Lexmark Optra C, T, and W series
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Xerox Phaser 850, 860 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}

=== USB Monochrome ===

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;10%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;10%&quot; |Postscript Support
! width=&quot;10%&quot; |GutenPrint Support
! width=&quot;20%&quot; |Hardware Issues 
! width=&quot;10%&quot; |Running Costs 
! width=&quot;20%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Postscript Support
| GutenPrint Support
| Hardware Issues 
| Running Costs 
| Opinion 
|-
| &lt;!--Description--&gt;Brother HL-1270N
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;BRScript
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Brother HL-3070CW Printer USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|BR-Script3 (PS3) untested}}
|-				
| &lt;!--Description--&gt;Brother HL5240 HL5240L 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;BRScript (PostScript Level 2) 
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Brother HL-7050N 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;BR3
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Brother MFC-7860DW Monochrome B/W BW 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;BR-Script BRScript (PostScript Level 3) 
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Brother HL4570CDWT
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Epson EPL-6200 Laser Printer USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|cheap to buy but untested - running cost unknown}}
|-		
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Kyocera FS-1370DN
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| HP LaserJet CP1515n USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|cheap to buy but untested - running cost unknown}}
|-
| &lt;!--Description--&gt;Lexmark Optra E312 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;built in? 
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}


=== USB Color ===

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;10%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;10%&quot; |Postscript Support
! width=&quot;10%&quot; |GutenPrint Support
! width=&quot;20%&quot; |Hardware Issues 
! width=&quot;10%&quot; |Running Costs 
! width=&quot;20%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Brother hl-3075cw
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;BR-Script 3 
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Brother MFC-9120CN 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;BRS3 
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;HP Color LaserJet 2500L (2003) USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{maybe|slow printing}}
|-
| HP Color LaserJet 2550L 2550Ln (2004) USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{maybe|slow printing}}
|-
| HP Color LaserJet CP1218, 2605, 3700, 4500, 4600, or 4650 series 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{maybe|slow printing}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Konica Minolta Magicolour 4650EN
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested}}
|-
| Kyocera FS-1010 FS-1010N 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested}}
|- 
| Kyocera FS-C5200DN
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested}}
|- 
| &lt;!--Description--&gt;Kyocera Mita FS-1030D 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;Kyocera FS-C5150DN 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Lexmark C540n 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested}}
|-
| Lexmark [http://www1.lexmark.com/products/view/Printers/Lexmark%20C780n/catId=cat10006-category&amp;prodId=3907-product C780n]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;{{yes|works PS3 emulation only}}
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| OKI C3600 Color Laser 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested}}
|- 
| &lt;!--Description--&gt;Samsung CLP-315
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;untested 
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| Xerox 618x Color Laser 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Postscript Support--&gt;
| &lt;!--GutenPrint Support--&gt;
| &lt;!--Hardware Issues --&gt;
| &lt;!--Running Costs --&gt;
| &lt;!--Opinion--&gt;{{N/A|untested }}
|-
|}

See [http://www.irseesoft.de/tp_drive7.htm here] for compatibility with TP7 (TurboPrint 7) Last update 2004. Not tested under emulation. Janus-UAE, Emumiga, 

OS3.x support via [http://aminet.net/package/comm/tcp/NetPrinter NetPrinter] and [http://www.os4depot.net/index.php?function=browse&amp;cat=driver/printer OS4 drivers] and [http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=33955&amp;forum=27#622365 experiences].

usbparallel.device

untested with USB-&gt;Centronics - The printer.class is rather 'clever'. It remembers to which unit the printers were connected (until you reboot). So if you first plug in Printer1, it gets unit 0, and Printer2 gets unit 1. If you now remove both printers and replug Printer2, it still will get unit 1 and not 0. This is used not to confuse the programs using the different units (moreover, if some program uses the usbparallel.device unit of an USB printer, and the printer is unplugged, the device unit cannot be freed immediately as the application still keeps it open). Sticking to the same units is generally a good idea I think (and therefore this mechanism is also used with all other classes creating exec.devices).

You may not send a short packet (packet less than maxpktsize == 64) nor zero byte packets until the very last byte of your printout. Otherwise the printer will silently ignore the data you sent. Some printer drivers print very short sequences that never fill the endpoint buffer, so printer ignore them. Bufferize all printer driver writes in the ieee1284.device and send them by epsize packets. So my hppsc2210 works fine with a classic HP560C driver, on a classic A2000 subwayized :)


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Beige cream D shape centronics end (Prolific chipset?) 
| 
| 
| 
| {{N/A|untested}}
|-
| Belkin F5U002v1 centronics end (chipset?) 
| 
| 
| 
| {{N/A|untested}}
|-
| Belkin F5U002VEA v2 centronics end (Prolific PL2305L chipset) 
| 
| 
| 
| {{N/A|untested}}
|-
| DYNAMODE USB-C-PP-1284 USB to 36pin (Prolific 2305 chipset) 
| 0x067b
| 0x2305
| 0x02
| {{N/A|untested but similar to BAFO below}}
|-
| IOGear GUC1284B 
| 
| 
| 
| {{N/A|untested}}
|-
| My-Link (raised ellipse on centronics plastic end) (unknown chipset) 
| 
| 
| 
| {{N/A|untested but more expensive }}
|-
| NEWLink (Prolific chipset?) 
| 
| 
| 
| {{N/A|untested}}
|-
| Targus PA096E centronics end (chipset?) 
| 
| 
| 
| {{N/A|untested}}
|-
| TRENDnet ware TU-P1284
| 
| 
| 
| {{N/A|untested}}
|-
| True PnP (Prolific chipset 2305) cheap 36pin Centronics (series of ridges along both short sides) 
| 0x067b
| 0x2305
| 2.00
| {{N/A|untested on BAFO BF-1284 but reports of poor quality and lack of support on other OSs }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| Transparent See Through Blue 
| 
| 
| 
| {{N/A|untested but possible poor quality build }}
|-
| Dynamode USB-PARALLEL 25pin female (prolific) 
| 0x067b
| 0x2305 
| 0x02 
| {{N/A|untested}}
|-
| FDL USB to 25pin 
| 
| 
| 
| {{N/A|untested}}
|-
| PlusKom USB to 25pin female connector for printer (IEEE 1284) 
| 
| 
| 
| {{N/A|untested}}
|-
| QinHeng Electronics (CH340S chipset) 
| 0x1a86
| 0x7584
| 
| {{N/A|untested curvy sides - flat top }}
|-
| StarTech 
| 
| 
| 
| {{N/A|untested}}
|-
| Syba SD-USB-DB25 
| 
| 
| 
| {{N/A|untested}}
|-
|}


==rawwrap.class - some old flatbed scanners supported==

Scandal is the MUI frontend to [http://www.ppa.pl/bugtracker/ Betascan Bugtracker] and [http://aminet.net/search?query=betascan Search for Betascan scanner drivers] derived from [http://www.sane-project.org/sane-backends.html sane backends] 


[http://www.sane-project.org/sane-backends.html#S-EPSON2 Epson2] 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Expression 1600 1640XL 1680 10000XL
| 0x04b8
| 0x0107 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Prefection 1200U, 1200 Photo, 
| 0x04b8
| 0x0104
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Perfection 1240U
| 0x04b8
| 0x010b
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{[https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=45760&amp;forum=25 works]|Needs 24V 0.8A psu but in Trident, click on &quot;Classes&quot;, then on &quot;rawwrap.class&quot;, then on &quot;Configure&quot;. There, under &quot;Global&quot;, activate the Option &quot;Bind to Vendor/Unknown Interfaces&quot;. Now go to the second tab &quot;Default Interface&quot; and select/enter these values: 
Default usbraw.device Unit: 0
Exclusive access: Yes
Out NAK Timeout: 20000ms
In NAK Timeout: 20000ms
In Buffer Mode: No buffering
Buffer Size: 36 KB
Short Reads Terminate: Yes
Now click on &quot;Use as Default&quot; and select &quot;Devices&quot; on the left. There, click on your scanner and click on &quot;Class Scan&quot;. Now close Trident by clicking on &quot;Save&quot;. }}
|-
| Perfection 1640SU Photo
| 0x04b8
| 0x010a
| 0x0104
| {{yes|works, even the transparency unit}}
|-
| Perfection 1650 Photo, 1660 Photo, 3200 Photo
| 0x04b8
| 0x011c
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Perfection 2400 Photo, 2450 Photo 
| 0x04b8
| 0x011b 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Perfection 4870 Photo, 4990 Photo, 
| 0x04b8
| 0x0128
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Perfection V700 V750 Photo
| 0x04b8
| 0x012c
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Stylus CX2800 2900 3200 3500 3600 3650 3700 3800 3900

Stylus CX4100 4200 3500 4600 4700 4800 4900 500 5100 5200 5300 5400 5900
| 0x04b8 
| 0x0802 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Stylus Office BX300F USB 
| 0x04b8
| 0x0848
| 
| {{yes| works with good scan quality}}
|-
|}


[http://www.meier-geinitz.de/sane/gt68xx-backend/ gt68xx] scanners based on the Grandtech GT-6801 and GT-6816 &quot;System-On-Chip&quot; scanner chipsets 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Artec Ultima 2000 and e+, Trust Flat Scan USB 19200 (ePlus2k.usb / Gt680xfw.usb) 
| 0x05d8
| 0x4002
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Genius Colorpage Vivid3x 4x 1200x
| 0x0458
| 0x2011 to 0x201f
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|  (ccd548.fw)}}
|-
| &lt;!--Description--&gt;Lexmark	X70	also X73 [http://subfusion.net/drivers/oslo3071b2.usb OSLO3071b2.usb]
| &lt;!--Vendor ID--&gt;0x043d
| &lt;!--Product ID--&gt;0x002d
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Medion/Lifetec/Tevion/Cytron MD/LT 9375 and Artec Ultima 2000, MD LT 9385 Gt680xfw.usb 
| &lt;!--Vendor ID--&gt;0x05d8
| &lt;!--Product ID--&gt;0x4002
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| BearPaw 2448 CS and TA Plus [http://www.meier-geinitz.de/sane/gt68xx-backend/firmware/A2Nfw.usb A2Nfw.usb]
| 0x055f
| 0x021a
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009  }}
|-
| Mustek BearPaw 1200 CS 
| 0x055f
| 0x021e
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|  ([http://www.meier-geinitz.de/sane/gt68xx-backend/firmware/A1fw.usb A1fw.usb])}}
|-
| &lt;!--Description--&gt;Mustek 1200 CU Plus Scanner [http://www.meier-geinitz.de/sane/gt68xx-backend PS1Dfw.usb / SBSfw.usb]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2000 }}
|-
| Mustek ScanExpress 1200 UB plus, Trust Compact Scan USB 19200, ScanMagic 1200 UB Plus
| 0x05d8
| 0x4002 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|  ([http://www.meier-geinitz.de/sane/gt68xx-backend/firmware/sbfw.usb sbfw.usb])}}
|-
| Mustek ScanExpress 1248 UB aka PC-World PC Line PCL-3000 
| 0x055f
| 0x021f
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| ([http://www.meier-geinitz.de/sane/gt68xx-backend/firmware/SBSfw.usb SBSfw.usb])}}
|-
| Mustek BearPaw 2400CS TA aka Goodmans GSC 12/24
| 0x055f
| 0x0218
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| (Transparency adapter untested) }}
|-
| BearPaw 2400 CS aka TA Plus
| 0x055f
| 0x0219
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|  (Transparency adapter) }}
|-
| Packard Bell Diamond 1200 Plus
| 0x055f
| 0x021c or 0x021b 
| 0x0
| {{yes|works - [http://www.meier-geinitz.de/sane/gt68xx-backend/ firmware required] but slow usb 1.1 speed with poor quality output (scanner fault not scandal)}}
|-
| Packard Bell Diamond 2400 Plus aka BearPaw 2400 CU Plus [http://www.meier-geinitz.de/sane/gt68xx-backend/ PS2Dfw2.usb firmware rename to PS2Dfw.usb]
| 0x055f
| 0x021d 
| 1.00
| {{yes|works slow usb 1.1 speed with ok quality output (scanner fault not scandal)}}
|-
| Plustek OpticPro 1248U
| 0x07B3
| 0x0400 0x0401
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| (ccd548.fw)}}
|-
| Plustek OpticSlim 2400
| 0x07b3
| 0x0422
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|  (cis3R5B1.fw)}}
|-
| Visioneer OneTouch 7300
| 0x04a7
| 0x0444
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|  (Cis3r5b1.fw)}}
|-
| &lt;!--Description--&gt;Mustek ScanEpress 1200 UB (Plus) clone [http://www.meier-geinitz.de/sane/ use mustek_usb backend]
| &lt;!--Vendor ID--&gt;0x055f
| &lt;!--Product ID--&gt;0x0006
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


Lexmark - needs testing
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Lexmark X1110 
| 
| 
| 
| {{N/A|untested}}
|-
| Lexmark X1140
| 
| 
| 
| {{N/A|untested}}
|-
| Lexmark X1150 
| 
| 
| 
| {{N/A|untested}}
|-
| Lexmark X1170 
| 
| 
| 
| {{N/A|untested}}
|-
| Lexmark X1180 
| 
| 
| 
| {{N/A|untested}}
|-
| Lexmark X1185
| 0x043d
| 0x007c
| 
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Lexmark X12xx 
| 
| 
| 
| {{N/A|untested in USB1.1, not fully tested in USB2.0}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Dell A920 
| 
| 
| 
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


HP - no driver
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| HP ScanJet 4100C
| 0x03f0 
| 0x0101
| 
| {{no|no driver}}
|-
| HP ScanJet 5200C
| 0x03f0 
| 0x0401
| 
| {{no|no driver}}
|-
| HP ScanJet 62X0C
| 0x03f0 
| 0x0201
| 
| {{no|no driver}}
|-
| HP ScanJet 63X0C
| 0x03f0 
| 0x0601
| 
| {{no|no driver}}
|-
| HP  
| 0x03f0
| 0x0102, 0x0105, 0x0205, 0x0305, 0x0405
| 
| {{no|no driver}}
|-
| HP
| 0x03f0
| 0x0705, 0x0805, 0x0901, 0x0a01
| 
| {{no|no driver}}
|-
| HP
| 0x03f0
| 0x1205, 0x1305, 0x2005, 0x2205
| 
| {{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


Plustek [http://www.sane-project.org/sane-backends.html#S-PLUSTEK LM983x] - no driver
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Plustek OticPro U12 UT12 UT16 U24 UT24
| 0x07B3
| 0x0010 to 0x0017
| 
| {{no|no driver}}
|-
| KYE/Genius Colorpage HR6-V2 HR6A HR7 HR7LE HR6X
| 0x0458
| 0x2008 to 0x2016 
| 
| {{no|no driver}}
|-
| Hewlett-Packard ScanJet 2100C and 2200C
| 0x03F0
| 0x0505 and 0x0605
| 
| {{no|no driver}}
|-
| Mustek BearPaw 1200 and 2400 
| 0x0400 	
| 0x1000 and 0x1001
| 
| {{no|no driver}}
|-
| UMAX 3400/3450 and 5400 	
| 0x1606
| 0x0050, 0x0060 and 0x0160 
| 
| {{no|no driver}}
|-
| Epson Perfection 1250 and 1260
| 0x04B8
| 0x010f and 0x011d
| 
| {{no|no driver}}
|-
| CANON CanoScan N650/656U N1220U D660U N670/676U N1240U LIDE20 LIDE25 LIDE30
| 0x04A9
| 0x2206 to 0x2220
| 
| {{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|}


[http://snapscan.sourceforge.net/ SnapScan] - no driver
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Acer Benq 310U, 320U, 340U
| 0x4a5
| 0x0
| 
| {{no|no driver}}
|-
| Acer Benq 620U, 620UT, 640U, 640UT
| 0x4a5
| 0x20
| 
| {{no|no driver}}
|-
| Acer Benq 1240 3300 4300
| 0x4a5
| 0x020
| 
| {{no|no driver}}
|-
| Agfa SnapScan e10 e20 e25 e26 e40 e42 e50 e52
| 0x06bd
| 0x20
| 
| {{no|no driver}}
|-
| Epson Perfection 660
| 0x04b8
| 0x0114
| 
| {{no|no driver}}
|-
| Epson Perfection 1270 1670
| 0x04b8
| 0x0
| 
| {{no|no driver}}
|-
| Epson Perfection 2480 2580
| 0x04b8
| 0x0
| 
| {{no|no driver}}
|-
| Epson Perfection 3490 3590
| 0x04b8
| 0x0
| 
| {{no|no driver}}
|-
| Mitsubishi
| 0x0
| 0x0
| 
| {{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}

==hub.class (self-powered and external ac powered hubs)==

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;Dynamode USB-H41 4 ports 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Belkin 4 Port 
| 
| 
| 
| {{yes|works}}
|-
| Conrad
| 
| 
| 
| {{yes|[http://www.a1k.org/forum/showthread.php?t=11432 works on a1k forum] }}
|-
| DLink DUB-H4 AC Adapter 
| 0x05e3
| 0x0608
| High 0200
| {{maybe|WARNING Genesys Logic Hub Broken - Will cause failures with USB}}
|-
| [http://service.targa.co.uk/faq.php?lang_id=2&amp;baseid=178&amp;artdesc=SilverCrest+USB+Hub+2040&amp;artid=760&amp;artpic=silvercrestHUB2040.jpg SilverCrest 4-port slim USB 2.0 HUB - HUB2040 (40775) - Targa GmbH]
| 0x05e3
| 0x0608
| 0901
| {{yes|works  Genesys Logic, Inc., [http://service.targa.co.uk/dokumente/USB_HUB_2040_0109_manual_EN.pdf Manual]}}
|-
| Skymaster
| 0x05e3
| 0x0605
| 060B
| {{yes|works}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| No Name active 4-port
| 0x1a40
| 0x0101
| 0111
| {{yes|works}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Thinkpad USB 3.0 Dock DU9019D1 
| &lt;!--Vendor ID--&gt;0x17e9
| &lt;!--Product ID--&gt;0x4302
| &lt;!--Revision--&gt;0014
| &lt;!--Opinion--&gt;{{Maybe|works a bit}} classed as dfu.class with two further USB 2.0 hubs - USB 3.0 ports detected and work (2.0 backwards compatibility) - DisplayLink DL-3900 with VIA VL811 chipset - usb ethernet not working - two dvi not working - 20V psu 2a (40w) with a 5.5 - 2.5mm tip (no bus power) - data through a-b printer/scanner usb lead - 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
|}


==Internet==

===rndis.class USB Tethering ===

The rndis class provides support for Ethernet access over Remote NDIS. Most USB based devices should be supported including smartfones.

Before opening Network Prefs, activate USB Tethering on the Smartfon, on Network prefs, type in usbrndis.device and tick &quot;Start Network during system boot&quot; and saved the configuration, the Connection is immediate no reboot is needed.

When restart AROS my Smartphone deactivates the connection and to access the network again, have to reactivate it before starting the browser.

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;Alcatel 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes|untested}}
|- 
| Huawei U8800
| 0x12d1
| 0x1039
| 
| {{yes|works}}
|- 
| &lt;!--Description--&gt;Huawei
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes|untested}}
|- 
| HTC (Android phone)
| 0x0bb4
| 0x0ffe
| 
| {{Yes|any android phone with usb tethering option}}
|- 
| &lt;!--Description--&gt;Nokia 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes|untested}}
|- 
| &lt;!--Description--&gt;Oppo 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes|untested}}
|- 
| &lt;!--Description--&gt;Samsung Galaxy 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes|untested}}
|- 
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
|- 
| &lt;!--Description--&gt;iPhone
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- 
| &lt;!--Description--&gt;Microsoft winPhone
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|}


===USB &amp;rarr; ethernet lan adaptor===

*2002 playstation 2 usb1.1 era - a little support but very old and slow 
*2006 wii asix era - a little support but very much miss than hit 
*2026 usb0: or eth0: of CDC Ethernet protocol (cdcether) with Ethernet Control Model (ECM) and [https://www.usb.org/document-library/class-definitions-communication-devices-12 others like Wireless Mobile Communication Devices WMC] and later CDC EEM (Ethernet Emulation Model) and NCM (Network Control Model) are USB Communication Device Class (CDC) protocols packing more Ethernet traffic over every USB bundle. For CDC Ethernet - NCM is better than EEM is better than ECM 


* USB1.1 Up to 010 meg broadband (1.25MBytes/s) - ADM8511, DM9601 poor speeds 
* USB2.0 Up to 400 meg broadband (60MBytes/s) - MCS7830, AX88772 a little especially the 2010 apple version but buy many as very very poor odds of working one 
* USB3.0 Over 400 meg broadband (60+MBytes/s) - not supported at the moment 


SANA (Standard Amiga Network Architecture) to usb 

ADMtek Infineon ADM8511 Pegasus II (USB 1.1 and 10Mbit/s - Sony PlayStation 2 network adapter) 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| 3Com 3c460b 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2001 }}
|-
| Abocom UFE1000 / Abocom DSB650TX
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Accton USB320-EC / Accton SpeedStream Ethernet
| 0x083a
| 0x0320
| &lt;!--Revision--&gt;
| {{unk|2002 }}
|-
| AEI USB Fast Ethernet / Allied Telesyn AT-USB100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2002 }}
|-
| ATEN UC-110T
| 0x0557
| 0x4000
|
| {{unk|2001 }}
|-
| BAFO USB To Ethernet Adapter BF-310
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2001 }}
|-
| Belkin F5D5050 v1 1101 
| 0x050D
| 
| &lt;!--Revision--&gt;
| {{maybe|2002 sometimes works from old amiga.org post which is now removed}}
|-
| Belkin F5D5050 v2 2101
| 0x050D
| 0x0121
| &lt;!--Revision--&gt;
| {{no|2006 does not works}} 
|-
| Belkin F5U122-PC
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Billionton USB-100 / Billionton USBLP-100
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Billionton USBEL-100 / Billionton USBE-100
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Compex LinkPort/UE202A
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| D-Link DSB-H3ETX
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| D-Link DSB-650 / D-Link DSB-650TX / D-Link DSB-650TX-PNA
| 0x2001
| 0x4000
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| D-Link DU-E10 / D-Link DU-E100
| 0x2001
| 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Edimax USB Ethernet Adapter EU-4201 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Elsa AG MicroLink USB2 Lan Ethernet adapter
| 0x05cc
| 0x3000
| &lt;!--Revision--&gt;1.01
| &lt;!--Opinion--&gt;{{unk| }}
|-
| GetNet
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| GIGABYTE GN-BR402W Wireless Router
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Goodway Fellowes USB UE-120 REV:V1 UE120 ADMTek 1011594 HO2419741 
| &lt;!--Vendor ID--&gt;0x07a6
| &lt;!--Product ID--&gt;0x0986
| &lt;!--Revision--&gt;0001
| &lt;!--Opinion--&gt;{{maybe|2001 USB Specification 1.1 compliant}} 
|-
| GWC Tech USB Ethernet Adapter
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Hawking UF100
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| HP HN210E / I/O DATA USB ETTX / Kingston KNU101TX
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Jinco USB Ethernet Adapter 10/100 Base-T UE-110
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Kouwell USB to Ethernet 588A
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Linksys USB10T / TA / TX
| 0x066b
| 0x2202
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|untested - possible peg1/peg2}}
|-
| Linksys (Cisco) USB100TX / H1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Logitec LAN-TX/U1 H2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| [http://www.mayflash.com/psps2/ps2024/ps2024.htm Mayflash PS2024] Playstation2 compatible clone of Proxim/Farallon NetLine?
| 0x07a6
| 0x8511
| &lt;!--Revision--&gt;1.01
| &lt;!--Opinion--&gt;{{maybe|works with DHCP router option on old 32bit distros but not on newer 64bit, best to go asixeth apple 2010 but buy many of them as poor success rate i.e. a lottery}}
|-
| Netgear FA101
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Philips CPWUE01/00 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Planet UE-9500 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| PlayStation 2 SCPH-10000 50000 models 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Proxim (formerly Farallon) NetLine USB PN796-650
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Siemens SpeedStream USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| SOHOware NUB100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| SMC EZNET-USB 2202USB/ETH / SMC 2206USB/ETH
| 0x0707
| 0x0100 0x0200 0x0201
| &lt;!--Revision--&gt;
| {{unk|untested but should work very well }}
|-
| Surecom EP-1427X 100/10M
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Target USB to 10/100M Fast Ethernet Converter
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Trendnet TU-ET100C
| 0x07a6
| 0x8511 
| &lt;!--Revision--&gt;0x0
| {{yes| sometimes works well, very stable}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;Digitus USB NIC DN-3016-A 
| 0x07a6
| 0x8513
| 1.01
| {{unk|untested new chipset }}
|-
| Digitus lanusb ADM8515
| 0x07a6
| 0x8515
| 1.01
| {{unk|untested because new chipset }}
|-
| VE285 usblan ADMtek 8515 
| 0x07a6
| 0x8515
| 1.01
| {{no|not working as new chipset }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


Davicom DM9601 eth (USB 1.1 and up to 10Mbit/s) 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Davicom USB-100 see clone below 
| 0x0a46
| 0x9601
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2001 }}
|-
| [http://wiki.maemo.org/USB_to_ethernet_networking chinese translucent transparent crystal blue] but variants are also found in clear, white and black. Just over 6&amp;nbsp;cm long. 
| 0x0a46
| 0x9601
| 0x0
| {{yes|2002 success can be sporadic so technically okay, but lacking in reliability. Out of 4 tested by me, only 2 worked. One case cracked open. }}
|-
| Corega FEther USB-TXC
| 0x07aa
| 0x9601
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Dynamode USB-NIC-1427-100
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Hirose USB-100
| 0x0a47
| 0x9601
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| KY-RS9600
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes|[http://www.amiga.org/forums/showpost.php?p=585358&amp;postcount=12 works] }}
|-
| ShanTou ST268 USB NIC
| 0x0a46
| 0x0268
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| ZT6688 USB NIC 
| 0x0a46
| 0x6688
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;ICS Advent DM9601 USB 2.0 10/100M Ethenet Adaptor JP1081B 
| &lt;!--Vendor ID--&gt;0x0FE6
| &lt;!--Product ID--&gt;0x9700
| &lt;!--Revision--&gt;0101
| &lt;!--Opinion--&gt;{{No|not working 32bit and 64bit - USB 1.1 10M ethernet}} 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
|}


MosChip MCS7830 (USB 2)
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Digitus DN-10050
| 0x9710
| 0x7830
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2004 }}
|-
| Edimax [http://www.edimax.co.uk/images/Image/datasheet/USB/EU-4206/EU-4206.pdf EU-4206]
|
| 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2005 }}
|-
| Speed Dragon 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| STLabs 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| StarTech Compact USB2105S [http://www.kustompcs.co.uk/acatalog/info_6790.html USB2106S]
| 0x9710
| 0x7830
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2007 }}
|-
| Sunrich Technologies [http://www.st-lab.com/admin/upfile/UploadFile/manual/manual(u-250).zip U-250]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2006 }}
|-
| Syba 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;MCS 7832 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2008 }} 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
|}


* USB2 [https://www.asix.com.tw/en/product/USBEthernet Asix Ethernet] AX88178A, AX88772C, AX88772B, AX88772A (wii), AX88172A 
* USB3 AX88179A, AX88179  

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| AirLink101 AGIGAUSB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009  AX88172}}
|-
| ATEN UC210T 
| 0x0557
| 0x2009
| 0x
| &lt;!--Opinion--&gt;{{unk| AX88172}}
|-
| &lt;!--Description--&gt;Billionton Systems USB2AR
| &lt;!--Vendor ID--&gt;0x08dd
| &lt;!--Product ID--&gt;0x90ff
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| }}
|-
| &lt;!--Description--&gt;Buffalo LUA-U2-KTX
| &lt;!--Vendor ID--&gt;0x0411
| &lt;!--Product ID--&gt;0x003d
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| }}
|-
| &lt;!--Description--&gt;corega FEther USB2-TX
| &lt;!--Vendor ID--&gt;0x07aa
| &lt;!--Product ID--&gt;0x0017
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no| }}
|-
| D-Link DUB-E100 up to rev A4
| 0x2001
| 0x1a00
| 
| &lt;!--Opinion--&gt;{{No| }}
|-
| &lt;!--Description--&gt;D-Link DUB-E100 rev B1 onwards 
| 0x07d1 or 0x2001 
| 0x3c05
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Maybe|AX88172 works on Deneb with [http://amigax.com/2010/02/21/usb-ethernet-speed-test-amigaos-4-0-classic/ Amiga OS4 Classic] and [http://www.a1k.org/forum/showthread.php?t=11432 on a1k] }}
|-
| &lt;!--Description--&gt;goodway corp USB gwusb2e
| &lt;!--Vendor ID--&gt;0x1631
| &lt;!--Product ID--&gt;0x6200
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Hawking UF200 
| 0x07b8
| 0x420a 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;[Linksys USB200M] 
| 0x077b
| 0x2226
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes|[http://www.amiga.org/forums/showpost.php?p=585601&amp;postcount=20 works] }}
|-
| &lt;!--Description--&gt;Netgear FA120 
| 0x0846 
| 0x1040
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested 2002 10/100 Rev.B1&quot; is silkscreened on the board of the device populating this entry (S/N: FA12254CB100409, date code 0508). This device may be manuf. by [http://www.cameo.com.tw/ Cameo] &quot;AX88172 L&quot;, &quot;F05040157&quot;, and &quot;ED3&quot; Chip1 ASIX AX88172  Chip2 Realtek RTL8201BL}}
|-
| &lt;!--Description--&gt;Intellinet
| 0x0b95 
| 0x1720
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;JVC MP-PRX1 Port Replicator
| &lt;!--Vendor ID--&gt;0x04f1
| &lt;!--Product ID--&gt;0x3008
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;ST Lab USB Ethernet
| &lt;!--Vendor ID--&gt;0x0b95 
| &lt;!--Product ID--&gt;0x1720
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Sitecom LN-029 &quot;USB 2.0 10/100 Ethernet adapter&quot;
| &lt;!--Vendor ID--&gt;0x6189
| &lt;!--Product ID--&gt;0x182d
| &lt;!--Revision--&gt;0
| &lt;!--Opinion--&gt;{{No| }}
|-
| &lt;!--Description--&gt;Surecom EP-1427X-2
| &lt;!--Vendor ID--&gt;0x1189
| &lt;!--Product ID--&gt;0x0893
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| }}
|-
| &lt;!--Description--&gt;TrendNet TU2-ET100 v2
| 0x07b8
| 0x420a 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Maybe|version 2}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;A-LINK NA1GU 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 88772}}
|-
| &lt;!--Description--&gt;AirLink101 ASOHOUSB Wii 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;AirLive EtherWe-1000U 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;APPLE AX88772 Model No. A1277 MC704LL/A P/N 825-7098-A 
| &lt;!--Vendor ID--&gt;0x05ac 
| &lt;!--Product ID--&gt;0x1402
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2008  usb2, }}
|-
| &lt;!--Description--&gt;APPLE Model No. A1277 (MB442Z/A 0885909217434) MC704ZM/A PN 825-7579-A 
| &lt;!--Vendor ID--&gt;0x05ac 
| &lt;!--Product ID--&gt;0x1402
| &lt;!--Revision--&gt; 
| &lt;!--Opinion--&gt;{{Maybe|2010 model, usb2 and controller AX88772 where prehaps 1in3 units working with owb - really poor odds i.e. a lottery, could be situation where various ethernet phy chipsets are used - press Use in network prefs after Save initial setup typing in usbasixeth.device, }}
|-
| &lt;!--Description--&gt;ASIX AX88772 bulbous casing 
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x7720 
| &lt;!--Revision--&gt;0x0
| &lt;!--Opinion--&gt;{{maybe|2008 works on 32bit and 64bit though setup can take a few attempts but may have issues with phy ethernet chip changing,  }}
|-
| &lt;!--Description--&gt;Datel Wii Lan Adapter DUS0204 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2007 }}
|-
| &lt;!--Description--&gt;EdiMax EU-4207 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008 }}
|-
| &lt;!--Description--&gt;Goodway HE2230 Maplin ASIX 88772 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008 }}
|-
| &lt;!--Description--&gt;Intec LAN G5626 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008 }}
|-
| &lt;!--Description--&gt;LevelOne USB-0202
| 0x0b95
| &lt;!--Product ID--&gt;0x07720
| &lt;!--Revision--&gt;0x
| &lt;!--Opinion--&gt;{{unk|2008 }}
|-
| &lt;!--Description--&gt;LevelOne USB-0301
| 0x0b95
| &lt;!--Product ID--&gt;0x07720
| &lt;!--Revision--&gt;0x
| &lt;!--Opinion--&gt;{{unk|2009 }}
|-
| &lt;!--Description--&gt;Linksys USB200M Rev 2
| &lt;!--Vendor ID--&gt;0x13b1
| &lt;!--Product ID--&gt;0x0018
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{maybe|2008 sparsely randomly working AX88772 or with &quot;Sana-II Meter Tool 37.11&quot; network monitoring program, showing continuous &quot;Bad Packet&quot; errors which could means &quot;CRC&quot; errors}}
|-
| &lt;!--Description--&gt;Linksys USB300M 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{maybe|2009 AX88772  }}
|-
| &lt;!--Description--&gt;Mayflash W001 or clones Lupo/PEGA S-Wii-0680 light gray rectangular with third of one top 45 degree angled slope
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x7720 
| &lt;!--Revision--&gt;0x0
| &lt;!--Opinion--&gt;{{unk| may have randomly changed phy ethernet chips, }}
|-
| &lt;!--Description--&gt;Max Value MVF00446 ASIN B006EG568A 
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x7720 
| &lt;!--Revision--&gt;0x0
| &lt;!--Opinion--&gt;{{Maybe|Trident prefs recognises as AX88772 sometimes works on 32bit and 64bit}} 
|-
| &lt;!--Description--&gt;NEWLink N14050 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;NEWLink Wii-ETH USB2.0
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Nintendo Wii LAN Adaptor 2110566 and clones 
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x07720
| &lt;!--Revision--&gt;0x
| &lt;!--Opinion--&gt;{{Maybe|Poseidon recognises as AX88772 with usbasixeth.device sometimes works seems different ethernet phy chips can be matched affecting compatibility}} 
|-
| &lt;!--Description--&gt;Nyko Wii Net Connect 87024
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes|[http://www.amiga.org/forums/showpost.php?p=585624&amp;postcount=22 works] }}
|-
| &lt;!--Description--&gt;0Q0 cable ethernet
| &lt;!--Vendor ID--&gt;0x1557
| &lt;!--Product ID--&gt;0x7720
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Plugable USB2-E100 (2009/2010) Bulbous housing 
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x7720 
| &lt;!--Revision--&gt;0x0
| &lt;!--Opinion--&gt;{{Maybe|Trident prefs recognises it as ax88772A and typing in usbasixeth.device sometimes works}}
|-
| &lt;!--Description--&gt;Sabrent KINAMAX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;SpeedLink SL-3401-SGY 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;TrendNet TU2-ET100 v3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;UGreen 20254 USB2 to 10/100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| AX88772}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;Afunta Apple-style White USB2.0 I/O Crest SY-ADA24005 ASIX Electronics Corp. AX88772A Fast Ethernet Adapter 
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x772a
| &lt;!--Revision--&gt;0x
| &lt;!--Opinion--&gt;{{no|usbasixeth.device accepted by network prefs but does not work}}
|-
| &lt;!--Description--&gt;Amazon Basics USB 2.0 AX88772A
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Digitus DN-10050-1
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x772a
| &lt;!--Revision--&gt;0x0 
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Edimax EU-4230  
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x772a
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Sabrent KINAMAX NT-USB20 AX88772A 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt; AX88772B USB 2.0 to 10/100M 
| &lt;!--Vendor ID--&gt;0x0B95
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2010  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;0x0B95
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;EdiMax EU-4208 
| &lt;!--Vendor ID--&gt;0x0B95
| &lt;!--Product ID--&gt;0x772b
| &lt;!--Revision--&gt;0x
| &lt;!--Opinion--&gt;{{No|Detected but not working}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;0x0B95
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;StarTech USB2100 ASIX AX88772C 
| &lt;!--Vendor ID--&gt;0x0B95
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;0x0B95
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;[https://www.asix.com.tw/en/product/USBEthernet/High-Speed_USB_Ethernet/AX88772D AX88772D]
| &lt;!--Vendor ID--&gt;0x0B95
| &lt;!--Product ID--&gt;0x1790
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;0x0B95
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;[https://www.asix.com.tw/en/product/USBEthernet/High-Speed_USB_Ethernet/AX88772E AX88772E]
| &lt;!--Vendor ID--&gt;0x0B95
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;0x0B95
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;AX88178 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2004 }} 
|-
| &lt;!--Description--&gt;Plugable USB2-E1000 i.e. USB 2.0 to Gigabit Ethernet 10/100/1000 LAN 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011 ASIX AX88178 Controller and Realtek RTL8211CL PHY}}
|-
| &lt;!--Description--&gt;AX88178A USB 2.0 to 10/100/1000M Gigabit Ethernet controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2005 }} 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;AmazonBasics USB3.0 adapter [https://github.com/nothingstopsme/AX88179_178A_Linux_Driver AX88179] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Cable Matters SuperSpeed USB 3.0 RJ45 adapter 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Hori Nintendo Switch 1 USB3 ethernet AX88179 
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x1790
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2017 AX88179 not binding to asixeth.class }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Plugable USB3-E1000  
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x1790
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2020 ASIX AX88179 not binding to class, USB 3.2 Gen1 to Gigabit Ethernet controller with integrated 10/100/1000Mbps Gigabit Ethernet PHY}}  
|-
| &lt;!--Description--&gt;Plugable AX88179 = [https://plugable.com/products/usb3-e1000-deal USB3-E1000] before mid-2023 or USB3-E1000; AX88179A = USBC-E1000 after mid-2023
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022  controller is AX88179 phy is ??, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;StarTech USB31000SPTW ax88179 
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x1790
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no| AX88179 not binding to asixeth.class, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;StarTech USB31000NDS AX88179 USB-A
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;StarTech US1GC301AU AX88179 USB-c
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;StarTech US1GC30B2 AX88179A USB-c
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;StarTech USB32000SPT AX88179A USB-c Rev 1 (AX88179) Rev 2 (AX88179A) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;USB32000SPT the Lot code sticker will have a bar code accompanied by a 10 digit number. The 5th and 6th digits of this lot code number would signify the revision. (Ex. xxxx02xxxx which would indicate rev. 2)
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;SYBA SY-ADA24029 Gigabit AX88179 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| }} may depend on the PHY chip connected to the controller chipset
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;TP-Link UE306 AX88179 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;TeckNet® Orico UL677G 10/100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;TeckNet® UL688G USB 3.0 10/100/1000 Base-T Ethernet port 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;AX88179 178A 
|-
| &lt;!--Description--&gt;Tecknet UL699G 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;TrendNet TU2-ET100 v6 
| &lt;!--Vendor ID--&gt;0x07b8
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|no support }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;uGreen 50922 USB3-A to 100/1000 dark grey rounded barrels 
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no| ax88179 not binding to asixeth.class, }}
|-
| &lt;!--Description--&gt;UGreen USB3-C to 100/1000 
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x1790
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;uGreen CR111 20256 usb3 a black plastic 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| AX88179}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;  AX88179A 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Plugable USB3-E1000 USBC-E1000 after mid-2023 i.e. AX88179A 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;StarTech USB31000SPTB 
| &lt;!--Vendor ID--&gt;0x0b95
| &lt;!--Product ID--&gt;0x1790
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|  AX88179A USB-A, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;  AX88179B
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|}


==USB  &amp;rarr; SerialPort Converter==

*2002 some support for early revisions of PL2303 
*2005 Prolific PL2303H PL-2303X and Pl-2303HX (same usb ids as pl2303) no support 
*2025 FTDI 232R [https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1135&amp;highlight=232r&amp;rowstart=20 work in progress] 
*2026 CDC-ACM i.e. Serial port over USB standard 

serialpl2303.class make sure you specify serialpl2303.device or Echo &quot;Test&quot; &gt;SER1: 

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| ATEN UC-232A 
| 0x0557 
| 0x2008 
| Full 0x0300
| {{N/A|untested}}
|- 
| IOGear GUC232A 
| 0x0557  
| 0x2008 
| Full 0x0110
| {{N/A|untested}}
|- 
| Alcatel 
| 0x11f7 
| 0x02df 
|
| {{N/A|untested}}
|- 
| BAFO BF-810 
| 0x067B  
| 0x2303 
| 0x0
| {{N/A|untested}}
|- 
| Belkin F5U103 
| 0x
| 0x
| 0x0
| {{N/A|untested}}
|- 
| Davibe SP611 
| 0x067B 
| 0x2303 
| 0x0 
| {{N/A|untested}}
|- 
| Dcu10 
| 0x0731
| 0x0528
| 
| {{N/A|untested}}
|- 
| Elcom 
| 0x056e
| 0x5003
| 
| {{N/A|untested}}
|- 
| IOData 
| 0x04bb 
| 0x0a03 
| 0x0
| {{N/A|untested}}
|- 
| Itegno 
| 0x0eba
| 0x1080
| 
| {{N/A|untested}}
|- 
| Nokia CA42 
| 
| 
| 
| {{N/A|untested}}
|- 
| Radioshack 
| 0x1453
| 0x4026
| 
| {{N/A|untested}}
|- 
| Ratoc 
| 0x0584
| 0xb000
| 
| {{N/A|untested}}
|- 
| Samsung 
| 0x04e8
| 0x8001
|
| {{N/A|untested}}
|- 
| Siemens DCA-510 
| 0x067B 
| 0x2303 
| 0x0 
| {{N/A|untested}}
|- 
| Sitecom CN104
| 0x6189
| 0x2068
|
| {{N/A|untested}}
|- 
| Sitecom CN116 
| 0x6189
| 0x2068
|
| {{N/A|untested}}
|- 
| Some Cut Ma620 
| 0x0df7
| 0x0620
| 
| {{N/A|untested}}
|- 
| Speed Dragon Multimedia MS3303H 
| 
| 
| 
| {{N/A|untested}}
|- 
| Syntech 
| 
| 
| 
| {{N/A|untested}}
|- 
| &lt;!--Description--&gt;Tripp 
| 0x2478
| 0x2008
| 
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;Airlink101 AC-USBS
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver }}
|-
| &lt;!--Description--&gt;Belkin F5U103v
| 0x067B  
| 0x2303 
| 0x0
| {{no|no driver }}
|- 
| Dynamode U232-P9
| 0x067B
| 0x2303
| 300
| {{no| no driver [http://koti.mbnet.fi/lonnberg/pl2303x.html linux patch] and using lsusb -v -d 067b:2303 gave bMaxPacketSize as 64 - pl2303x }}
|- 
| Konig CABLE-146/2 USB to RS232 
| 0x067b
| 0x2303
| 400
| {{no|no driver }}
|-
| MANHATTAN 205146 USB to Serial Converter
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver }}
|- 
| Sabrent SBT-USC1M
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver }}
|-
| &lt;!--Description--&gt;Trendnet TU-59
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver }}
|-
| &lt;!--Description--&gt;Unbranded black case and lead USB 232 Converter
| &lt;!--Vendor ID--&gt;0x067B
| &lt;!--Product ID--&gt;0x2303
| &lt;!--Revision--&gt;0300
| &lt;!--Opinion--&gt;{{No| }}
|-
|}


[http://www.ftdichip.com/index.html Future Technology Devices International Ltd FTDI]-FT232R.class [https://ftdichip.com/software-examples/code-examples/c-builder/ FTProg src], [http://rtr.ca/ft232r/ ft232r src], [https://ftdichip.com/wp-content/uploads/2020/08/DS_FT232R.pdf FT232R datasheet], [], 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;0x0403
| &lt;!--Product ID--&gt;0x6001 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} [https://www.youtube.com/watch?v=1GE-gKgHxZI beware of cheap clones fake with s/n A50285BI SN]
|-
| &lt;!--Description--&gt;Lynx Astro FTDI 
| &lt;!--Vendor ID--&gt;0x0403
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} FT232R 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;Sabrent CB-FTDI
| &lt;!--Vendor ID--&gt;0x0403
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| {{no|no driver TTL-232R cables use FTDI's [http://n1mm.hamdocs.com/tiki-index.php?page=USB+Interface+Devices FT232RQ ic device] }}
|-
| &lt;!--Description--&gt;Startech.com 1 Port FTDI USB to Serial RS232 DB9M Adapter Cable with COM Retention ICUSB2321F 
| &lt;!--Vendor ID--&gt;0x0403
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} FT232RL Chipset
|-
| &lt;!--Description--&gt;StarTech.com 2 Port FTDI USB to Serial RS232 Adapter Cable ICUSB2322F
| &lt;!--Vendor ID--&gt;0x0403
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} FTDI FT2232D Chipset
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} FT232RL is the SSOP-28 and the FT232RQ is the QFN-32 package option 
|}


[https://www.onetransistor.eu/2017/08/ch341a-mini-programmer-schematic.html ch341a.class] 

*I2C EEPROMS (3.3V and 5V) compatible and also SPI FLASH memories (3.3V devices) making sure 1.8V is covered  
*each having their own [https://winraid.level1techs.com/t/guide-how-to-use-a-ch341a-spi-programmer-flasher-with-pictures/33041 4x2 connection blocks] using [https://github.com/flashrom/flashrom flashrom] 

 sudo flashrom --programmer ch341a_spi -r backup.bin
 sudo flashrom --programmer ch341a_spi -w &lt;new bios name&gt;

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;Jiangsu QinHeng Ltd CH341A emulate UART communication, standard parallel port, memory parallel port and synchronous serial (I2C, SPI) 
| &lt;!--Vendor ID--&gt;0x1A86
| &lt;!--Product ID--&gt;0x5512
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;QinHeng USB2.0-Serial HL-340 
| &lt;!--Vendor ID--&gt;0x1A86
| &lt;!--Product ID--&gt;0x7523
| &lt;!--Revision--&gt;0252
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|}


==simplemidi.class and CAMD==

Currently support includes 

* simplemidi.class SimpleMidi maps some keyboard keys to corresponding computer keys as used by music trackers to emulate a musical keyboard 
* camdusbmidi.class follows the rules of the m68k implementation of Commodore's CAMD midi specification and usb class compliant 

for 

* usb host like a computer 
* usb device controllers - keyboards, drum machines, djay turntables, grooveboxes, etc 
* interfaces - cables or boxes which convert usb to 5pin DIN plug midi 


What is needed is a fully class-compliant '''brand name''' USB MIDI keyboard, especially manufactured in the last 10 years are best 

*Arturia
*Novation
*M-Audio
*Akai

Plugging this in one of your USB ports, the camd.library will make the keyboard's MIDI IN/OUT ports available in the system. 

Then select the keyboard's MIDI IN port (known as a &quot;cluster&quot; in CAMD) for input, and the software instrument's cluster as output 


ShowCluster (shows midi ports available in and out)

MidiWatch (usually port usbmidi.in.0 less often usbmidi.out.0) (Ctrl-C to end output stream) 
 usbmidi.in.0 Message on channel 01, NoteOn  90  39  08  00
 usbmidi.in.0 Message on channel 01, NoteOff 80  39  00  00

MidiThru (forwards messages from one port to another)
 run &gt;nil: c:midithru usbmidi.out.0 usbmidi.out.2 

MidiSendC (sends a middle C to a specific port)


Midi Controller + Sound Module (together aka as a synth) -&gt; Audio Output 


The difference between midi and midi over USB is that in old school Midi the transmitter transmits whenever it wants and the receiver always has to be prepared to receive data. Easy to do at the rate of a 1990's modem speed these days.

USB over midi.. turns midi into a polled protocol.. So the USB host (typically the computer) has to ask &quot;do you have anything for me&quot; before the remote will send. If the USB host gets busy doing other things or there is a lot of things on the USB bus to get polled, you can get delays.

For its age midi is still a great protocol for music

* [https://www.usb.org/sites/default/files/midi10.pdf USBIF's &quot;USB Device Class Definition for MIDI Devices&quot; document, version 1.0 from Nov 1, 1999]
* [https://www.usb.org/sites/default/files/USB%20MIDI%20v2_0.pdf MIDI v2.0 from 2020 which AROS still needs, adds support for MIDI 2.0, MIDI-CI, and Universal MIDI Packet] 

Nearly all synthesizers now use the 16 MIDI channels available on a MIDI bus in one instrument alone, requiring multiple MIDI busses in a typical setup with more than
one MIDI instrument. In addition, by handling multiple &quot;virtual&quot; cables, USB offers a solution to go beyond MIDI's 16-channel limit. 

MIDI data is transferred over USB using 32-bit USB-MIDI Event Packets. These packets provide an efficient method to transfer multiple MIDI streams with fixed length messages. The 32-bit USB-MIDI Event Packet allows multiple &quot;virtual MIDI cables&quot; routed over the same USB endpoint. This approach minimizes the number of required endpoints. It also makes parsing MIDI events easier by packetizing the separate bytes of a MIDI event into one parsed USB-MIDI event. 


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;25%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;15%&quot; |CAMD
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;Computer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{Yes|which acts as USB midi host to get all usb devices talking together}} 
|-
| &lt;!--Description--&gt;Hobbytronics usb host standalone 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;bomebox 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;raspberry pi with several midi interface(s) and linux scripting 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Kenton MIDI USB Host mk3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|}


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;25%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;5%&quot; |Product ID
! width=&quot;5%&quot; |Revision 
! width=&quot;15%&quot; |CAMD
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;Acorn Instruments Masterkey 49 device 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 untested usb powered 5V regulated - similar keybed to keystation 49es but unplug then re-plug the USB cable while it is powered the device might reconnect 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe| }}
| &lt;!--Opinion--&gt; midi keyboard controller 
|-
| &lt;!--Description--&gt;Akai SynthStation 25 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2010 - sticky rubber keys - usb 
|-
| &lt;!--Description--&gt;Akai MPK Mini Laptop Production Keyboard 
| &lt;!--Vendor ID--&gt;0x09e8
| &lt;!--Product ID--&gt;0x007c
| &lt;!--Revision--&gt;0100
| &lt;!--CAMD--&gt;{{Yes|detected and camd usb to use, not tested with apps}}
| &lt;!--Opinion--&gt;2010 25 mini key self powered by mini USB lead - sustain port - no top left corner joystick - tested icaros 2.3 -  
|-
| &lt;!--Description--&gt;Akai LPK25 LPK37 LPK49 Laptop Production Keyboard
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested }}
| &lt;!--Opinion--&gt;2012 untested velocity sensitive mini keys with synth action - weak mini USB port - latency issues -  
|-
| &lt;!--Description--&gt;Akai Professional APC Key 25 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2012 
|-
| &lt;!--Description--&gt;Akai MPK49 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| untested}}
| &lt;!--Opinion--&gt;2012 untested 49 key 49-key full-sized, semi-weighted keyboard with aftertouch - 
|-
| &lt;!--Description--&gt;AKAI Max25 MAX49 control keyboard
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested }} 
| &lt;!--Opinion--&gt;2014 usb compliant 
|-
| &lt;!--Description--&gt;Akai Professional MPK249 MPK261 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}} 
| &lt;!--Opinion--&gt;2015 USB2 USB-b - full keys semi-weighted aftertouch - midi in out - sustain and peddle port 
|-
| &lt;!--Description--&gt;Akai Professional Advance 49
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2016 
|-
| &lt;!--Description--&gt;Akai MPK Mini MKII MK2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| untested}}
| &lt;!--Opinion--&gt;2017 untested USB2 USB-b midi connection only - 4 way thumb joystick top left - 25 tiny keys - velocity drum pads - plastic build quality - 
|-
| &lt;!--Description--&gt;AKAI Professional APC Key 25 MK2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| driver}}
| &lt;!--Opinion--&gt;2017 
|-
| &lt;!--Description--&gt;Akai MPK Mini Play
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2021 untested USB2 USB-b midi connection only - synth basic samples - class compliant? - small led display top centre - 25 mini keys - press and hold the &quot;Prog Select&quot; button then use the &quot;Program&quot; knob to assign a MIDI channel - 
|-
| &lt;!--Description--&gt;Akai MPK Mini 3 MKIII MK3 
| &lt;!--Vendor ID--&gt;0x09E8
| &lt;!--Product ID--&gt;0x1049 
| &lt;!--Revision--&gt;0200
| &lt;!--CAMD--&gt;{{Yes|detected audio class and bindings with camdusbmidi.class -  - midi in out untested - }}
| &lt;!--Opinion--&gt;2021 USB2 USB-b midi controller connection no 5pin legacy - small led display top centre - 25 mini keys goofy uneven feel of the akai keyboards - press and hold the &quot;Prog Select&quot; button and press pad 1 to 8 to assign a MIDI channel - tested on AROS One 2.4 usb
|-
| &lt;!--Description--&gt;Akai Force / MPC One 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{Maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Akai Pro MPK Mini Plus 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{Maybe| }}
| &lt;!--Opinion--&gt;2023 untested 37 mini keys - class compliant device - usb-b bus powered only with 5pin midi in and out - Shift and Global for Midi Ch - 
|-
| &lt;!--Description--&gt;Akai Pro Ableton Push Mk 1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Akai Professional MPC Key 37 49 61 midi controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| untested}}
| &lt;!--Opinion--&gt;2023 untested USB2 usb-b
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| CAMD
| Opinion 
|-
| &lt;!--Description--&gt;Alesis Photon PH-25 X25 Midi &amp; USB keyboard/synth
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2005 midi keyboard controller  
|-
| &lt;!--Description--&gt;Alesis Q25 Q49 Q61 Q88 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{Maybe| }}
| &lt;!--Opinion--&gt;2014 untested 
|-
| &lt;!--Description--&gt;Alesis Coda Pro Portable 88-Key Digital Piano USB MIDI Keyboard
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2015 
|-
| &lt;!--Description--&gt;Alesis V25 V49 V61 midi controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| untested}}
| &lt;!--Opinion--&gt;2017 
|-
| &lt;!--Description--&gt;Alesis V Mini 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{Maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Alesis VI49 VI61 midi controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{Maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Alesis VX49 VX61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2016 1 5-pin MIDI input, 1 5-pin MIDI output, 1 USB port,
|-
| &lt;!--Description--&gt;Alesis Q25 Q49 Q61 Mk2 MKII 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2018 
|-
| &lt;!--Description--&gt;Alesis Recital 88 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2020 
|-
| &lt;!--Description--&gt;Alesis V25 V49 V61 MK2 MKII 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2022
|-
| &lt;!--Description--&gt;Alesis Qmini portable 32-key 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2023 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;audiothingies MicroMonsta 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 untested synth - 
|-
| &lt;!--Description--&gt;audiothingies MicroMonsta 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019  synth - 
|-
| &lt;!--Description--&gt;Arturia Analog Experience “The Player” USB MIDI Master Keyboard Model APE25
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2010 usb-b bus powered - 
|-
| &lt;!--Description--&gt;Arturia MiniLab Mk1
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2013 maybe class complaint 
|-
| &lt;!--Description--&gt;Arturia MiniLab MkII Mk2
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2016 maybe class complaint 
|-
| &lt;!--Description--&gt;Arturia Keystep 32 
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{Maybe| }}
| &lt;!--Opinion--&gt;2016 untested 32 mini keys  usb compliant 
|-
| &lt;!--Description--&gt;Arturia KeyLab 61 88 
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{Maybe| }}
| &lt;!--Opinion--&gt;2017 untested hammer-action Fatar keybed - reset Press and hold Oct + and Oct – buttons then insert the USB cable - 
|-
| &lt;!--Description--&gt;Arturia MiniLab mkII
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt;0x2209 
| &lt;!--Revision--&gt;0100
| &lt;!--CAMD--&gt;{{Yes|detected audio class and bindings with camdusbmidi.class -  - midi in out untested - }}
| &lt;!--Opinion--&gt;2017 USB2 usb-b bus power - metal base heavier than most - Shift and press a key to select the MIDI Channel - To reset to original factory, unplug the USB cable, hold down the Oct- and Oct + buttons, plug the USB cable back in and continue to hold the buttons until the pads turn white - need software to change parameters like velocity sensitive assistance - 
|-
| &lt;!--Description--&gt;Arturia KeyLab MK2 MKII 61 88 
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested }}
| &lt;!--Opinion--&gt;2017 untested hammer-action Fatar keybed 
|-
| &lt;!--Description--&gt;Arturia MicroFreak
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2019 hybrid digital/analog synthesis, 
|-
| &lt;!--Description--&gt;[https://www.youtube.com/watch?v=PeYIAfn3UMs Arturia Minilab 3] [https://www.youtube.com/shorts/chj1WgMupGw ] [https://www.youtube.com/shorts/FMVdfhzg1Dw ]
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| untested}}
| &lt;!--Opinion--&gt;2020 untested usb-c bus powered - 25 mini keys semi - 
|-
| &lt;!--Description--&gt;Arturia Keystep Pro 
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2020 
|-
| &lt;!--Description--&gt;Arturia MiniLab 3 Mk3
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2022 maybe class complaint 
|-
| &lt;!--Description--&gt;Arturia MiniFreak
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2022 
|-
| &lt;!--Description--&gt;Arturia KeyLab Essential 49 61 88 mk3 
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2023 untested usb-c and 1 midi out - lack of aftertouch - 
|-
| &lt;!--Description--&gt;Arturia AstroLab 
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 
|-
| &lt;!--Description--&gt;Arturia KeyLab MK3 MKIII 61 88 
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2025 untested hammer-action Fatar keybed 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Behringer UMX61
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe|untested}}
| &lt;!--Opinion--&gt;2007 
|-
| &lt;!--Description--&gt;Behringer U-Control UMX490 UMX610 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2010 
|-
| &lt;!--Description--&gt;Behringer U-Control 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Behringer Swing 32-Key
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Behringer MOTOR 49 - 49-Key USB/MIDI Master Controller Keyboard
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| CAMD
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt; midi keyboard controller 
|-
| &lt;!--Description--&gt;Creative EMU Xboard 25 E-MU X-Board 49 61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|untested}}
| &lt;!--Opinion--&gt;2008 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;CME M-Key Mkey 49 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2008 stops sending MIDI on a regular basis. The simplest &quot;fix&quot; is to flip it off and on via the power switch at the back
|-
| &lt;!--Description--&gt;CME Ukey U-Key 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2009 
|-
| &lt;!--Description--&gt;CME Xkey 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2014 low-profile aluminium  full size pressure sensitive with polyphonic aftertouch but keys make too much noise and that they can be too sensitive to velocity - low power draw 25ma 
|-
| &lt;!--Description--&gt;CME M-Key 49 V2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2014 simplified version of the U-key Mobiltone 
|-
| &lt;!--Description--&gt;CME XKEY AIR 37
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2019
|-
| &lt;!--Description--&gt;cme xkey 37 le
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2020 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{ | }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Donner Spaceline DMK-25 Donnerdeal Rantion 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Donner DMK25 PRO 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;  25 mini velocity keys with limited aftertouch - usb-c powered - 8 drum pads - 3.5mm &quot;midi out&quot; socket - 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{ | }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Elektron Digitakt 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2015 expensive later midi usb class compliant with since 1.5 Update
|-
| &lt;!--Description--&gt;Elecktron Digitone 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Elektron Digitone Keys 37-key Digital FM Synthesizer
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2018 expensive 
|-
| &lt;!--Description--&gt;Elektron Analog Four MKII
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Elektron Octatrak MKII
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{ | }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;ESI keycontrol 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;ESI keycontrol 49+ 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;ESI keycontrol 25xt
| &lt;!--Vendor ID--&gt;0x2702 
| &lt;!--Product ID--&gt;0x2702
| &lt;!--Revision--&gt;0100
| &lt;!--CAMD--&gt;{{Yes|detected and usb driver working}}
| &lt;!--Opinion--&gt;2011 bus powered or 12v 0.5a dc in - metal base so heavy - midi out 5pin - sustain pedal port - modulation slider - rubber coated knobs becomes sticky - 
|-
| &lt;!--Description--&gt;ESI keycontrol 49xt 61xt 88xt 
| &lt;!--Vendor ID--&gt;0x2702
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;0100
| &lt;!--CAMD--&gt;{{Yes|detected}}
| &lt;!--Opinion--&gt;2011 12v 0.5a center pin +ve external psu required - USB i/o and 1 legacy 5pin out - full sized keys - heavy aluminium case keyboard metal base - 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Evolution MK-125 MK-149
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2000 9v 
|-
| &lt;!--Description--&gt;Evolution MK-225C MK-249C 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2003 9v 
|-
| &lt;!--Description--&gt;Evolution USB/Midi Controller MK-425C MK-449C MK-461C 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|25, 49, 61 keys -  }}
| &lt;!--Opinion--&gt;2006  9V or 12V - 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; midi keyboard controller 
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| CAMD
| Opinion 
|-
| &lt;!--Description--&gt;IK Multimedia iRig Keys Pro
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2014 37 full keys 
|-
| &lt;!--Description--&gt;IK Multimedia iRig Keys Pro Mobile
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2014 25 or 37 mini keys 
|-
| &lt;!--Description--&gt;IK Multimedia iRig Keys 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2020 mini velocity keys no aftertouch - 
|-
| &lt;!--Description--&gt;IK Multimedia iRig Keys 2 PRO 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2020 full velocity keys no aftertouch - 
|-
| &lt;!--Description--&gt;IK Multimedia iRig Keys 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Kawai VPC 1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt; weighted keys - heavy build - 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Keith McMillen Instruments K-Board
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt; omni class compliant to all channels? each keypad makes them velocity, pressure, and location sensitive but  not really suited for piano playing 
|-
| &lt;!--Description--&gt;Keith McMillen  BopPad
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt; omni class compliant to all channels? 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Korg NanoKontrol 1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;mini usb
|-
| &lt;!--Description--&gt;Korg Prophecy 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;KORG microKONTROL 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2010
|-
| &lt;!--Description--&gt;Korg microKEY 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| untested}}
| &lt;!--Opinion--&gt;2011 velocity-sensitive Natural Touch keys but  joystick is an alternative to the common pitch/modulation wheel design - power draw - 
|-
| &lt;!--Description--&gt;Korg nanoKey nanoPad 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2011 
|-
| &lt;!--Description--&gt;Korg Taktile 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Korg microKEY2 25 37 49 61 USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|2015 untested}}
| &lt;!--Opinion--&gt;2015 USB powered - semi weighted - 
|-
| &lt;!--Description--&gt;Korg MiniList 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Korg MinKey nanoPad nanoPad 2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Korg Nautilus 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; midi keyboard controller 
|-
| &lt;!--Description--&gt;Kurzweil PC3 7 series - Artis 7 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}} 
| &lt;!--Opinion--&gt;fatar TP-8 semi-weighted action  
|-
| &lt;!--Description--&gt;Kurzweil PC1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Kurzweil PC3 A8
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Line 6 Mobile keys 25
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2006 
|-
| &lt;!--Description--&gt;Line 6 POD Studio KB37 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2006 
|-
| &lt;!--Description--&gt;Line 6 Tone Port KB37 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2007 
|-
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| CAMD
| Opinion 
|-
| &lt;!--Description--&gt;Midiman (later M-Audio) Oxygen8 Ozone Ozonic 25 32 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no|not class compliant - untested 5pin legacy }}
| &lt;!--Opinion--&gt;2002 2004 untested - 25 full keys - slider/fader to left of lcd display - 
|-
| &lt;!--Description--&gt;m-audio oxygen keystation (61 key) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2004 
|-
| &lt;!--Description--&gt;M-Audio eKeys 37 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2005 
|-
| &lt;!--Description--&gt;M-Audio Axiom 25, 49, 61
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2006 bus powered and 12v psu - if sliders/faders are on right - legacy midi 5pin - chunky unit -
|-
| &lt;!--Description--&gt;M-Audio Oxygen 8v2, 49, 61 (silver) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2006 full size velocity sensitive 12v psu - sending random pitchbend info - 
|-
| &lt;!--Description--&gt;M-Audio Keystation 37e 49e, 61e MK1 MKI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2006 - ok key action - 
|-
| &lt;!--Description--&gt;M-Audio Keystation 37es 49se 61es, 88es MK1 MKI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 - 
|-
| &lt;!--Description--&gt;M-Audio Oxygen 25/49/61/88 (blue) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 [https://m-audio.com/products/view/oxygen-25-legacy advised Class-compliant and GM/GM2/XG SysEx messages] with full size velocity sensitive 12v psu - sending random pitchbend info - 
|-
| &lt;!--Description--&gt;M-Audio Axiom 25, 49, 61 (2nd Gen) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 semi-weighted mini keys - bus powered and 9v psu for 25/49 and 12v for 61 - if sliders/faders are on left - legacy midi 5pin - chunky unit - 
|-
| &lt;!--Description--&gt;M-Audio Axiom Pro 25, 49, 61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 poor construction 
|-
| &lt;!--Description--&gt;MAudio Axiom AIR 25 M-Audio Axiom Air Mini 32
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2012 
|-
| &lt;!--Description--&gt;M-Audio Oxygen 25 III (3rd Gen) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2012 untested - usb only - rubber keys sticky - 
|-
| &lt;!--Description--&gt;MAudio Keyrig 49 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;M-Audio Keystation Mini 32 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2012 - mini usb - plays a few notes and then stops responding randomly - try plugging it into port 1 or 2 on your pc - 
|-
| &lt;!--Description--&gt;M-Audio Keystation 49 MK2 II
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2012 USB port and class compliant
|-
| &lt;!--Description--&gt;M-Audio Keystation 61 MK3 MKIII MIDI keyboard
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2015 usb compliant untested 
|-
| &lt;!--Description--&gt;M-Audio Oxygen 25 IV
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| untested}}
| &lt;!--Opinion--&gt;2016  choice 
|-
| &lt;!--Description--&gt;M-Audio CTRL-49
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2017 
|-
| &lt;!--Description--&gt;M-Audio ProKeys 88, 88sx 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;M-Audio Keystation Mini 32 MK3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2019 mini usb - some power or incompatibility issue with the native USB ports of the laptop, plugged in a passive USB 2.0 HUB (not USB 3.0, not powered)
|-
| &lt;!--Description--&gt;[https://www.youtube.com/watch?v=3328SvuJsLw M-Audio Oxygen25 MKV]
| &lt;!--Vendor ID--&gt;0x0763
| &lt;!--Product ID--&gt;0x0001
| &lt;!--Revision--&gt;0023
| &lt;!--CAMD--&gt;{{Yes|detected audio class and bindings with camdusbmidi.class  - midi in out untested}}
| &lt;!--Opinion--&gt;2020 25 full size semi keys - USB2 usb-b but no 5pin classic plugs - channel select SHIFT button and CHANNEL on keybed - plastic build - holding down both the Octave + and - for factory reset -  more limited in what you can do with it than IV 4th one - tested on AROS One 2.4 usb
|-
| &lt;!--Description--&gt;M-Audio Oxygen Pro 25 49 61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2022 untested semi full keys 
|-
| &lt;!--Description--&gt;M-Audio Oxygen Pro Mini 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2023 untested - 32 smaller keys - not endless encoders - usb only - 
|-
| &lt;!--Description--&gt;M-Audio Hammer 88 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Moog 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Moog Minitaur 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;M-VAVE SMK-25mini 25key MIDI Control Keyboard Y6I0 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Native Instruments NI Primus A25 JamMate 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2008 not compliant, 
|-
| &lt;!--Description--&gt;Native Instruments Maschine MK1 MKI
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2009 not compliant uses snd-usb-caiaq module, 
|-
| &lt;!--Description--&gt;Native Instruments Komplete Kontrol S88 S61 S49 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2012 - weighted keys - 
|-
| &lt;!--Description--&gt;Native Instruments Maschine MK2 MKII 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe compliant, 
|-
| &lt;!--Description--&gt;Native Instruments Maschine Micro Mikro MK2 MKII
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 maybe? 
|-
| &lt;!--Description--&gt;NI Komplete Kontrol S49 S61 S88 MkII MK2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2017 all MK2 MK3 power up the keyboard using USB, it will set the keyboards MIDI port to computer MIDI only without any option to set it to use the MIDI DIN, meaning you cannot connect the keyboard to hardware and power from USB, you MUST power with the power adapter and physically unplug from any USB connection - 
|-
| &lt;!--Description--&gt;Native Instruments Komplete Kontrol A25 A49 A61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 maybe compliant,  
|-
| &lt;!--Description--&gt;[https://github.com/sikorak666/maschine-mikro-mk3-driver Native Instruments Maschine Micro Mikro Plus MK3 MKIII]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 
|-
| &lt;!--Description--&gt;Native Instruments Komplete Kontrol M32 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 untested 32 smaller keys - no drum pads - USB only - 
|-
| &lt;!--Description--&gt;NI Komplete Kontrol S49 S61 S88 MkIII MK3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2023 
|-
| &lt;!--Description--&gt;NI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2025 
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| CAMD
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; midi keyboard controller 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Neusonik iBoard 4
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Nektar Impact LX25+ LX49+ LX61+ LX88+ SE 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2017 budget full-size velocity-sensitive synth-action keyboard - 
|-
| &lt;!--Description--&gt;Nektar Impact GX49
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; USB port - 
|-
| &lt;!--Description--&gt;Nektar Panorama P4 P6 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  USB &amp; USB Micro B, 5-pin MIDI out, 2 x TRS inputs with 49 semi-weighted, velocity sensitive with aftertouch
|-
| &lt;!--Description--&gt;Nektar SE25 SE49
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; mini keys - micro usb bus powered - velocity and sustain button 
|-
| &lt;!--Description--&gt;Nektar Panorama P6 61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Nektar Panorama T6 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Nord Stage 3 midi controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; sysex 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Novation ReMote 25 49 61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2003 lhs XY touchpad and the joystick -
|-
| &lt;!--Description--&gt;Novation LaunchKey 25 49 61 88 Mk1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2005 not USB class compliant 
|-
| &lt;!--Description--&gt;Novation 49 61 SL 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2006 semi-weighted Fatar TP-8 or TP-9 keybed
|-
| &lt;!--Description--&gt;Novation ReMote 25SL 49SL 61SL soft label 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2006 - two long top liquid-crystal display LCD strips - XY touchpad and the joystick - 
|-
| &lt;!--Description--&gt;Novation ReMOTE 25LE 
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;0x0004
| &lt;!--Revision--&gt;0001
| &lt;!--CAMD--&gt;{{Yes|detected, usb driver in devs/midi for camd to use}}
| &lt;!--Opinion--&gt;2007 USB-b powered, 9v center pin positive or 6 MN1500 AA batteries - X/Y touchpad and the combined pitch and modulation joystick - no aftertouch but can use both the legacy MIDI OUT and USB port simultaneously 
|-
| &lt;!--Description--&gt;Novation Nocturn 49 61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{Unk| }} 
| &lt;!--Opinion--&gt;2008 untested sending random pitchbend info
|-
| &lt;!--Description--&gt;Novation 49 61 SL MkII
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2009 semi-weighted Fatar TP-8 or TP-9 keybed 
|-
| &lt;!--Description--&gt;Novation MiniNova 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2013 
|-
| &lt;!--Description--&gt;Novation Impulse 25 49 61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2012 velocity aftertouch‑sensitive semi-weighted keyboards and eight backlit pads -  USB, 5-pin MIDI out - 
|-
| &lt;!--Description--&gt;Novation Circuit Tracks / Rhythm 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2015 untested 
|-
| &lt;!--Description--&gt;Novation LaunchKey 25 49 61 88 MK2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2015 USB class compliant - full keys - 
|-
| &lt;!--Description--&gt;Novation Launchpad Mini MK2 MKII
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 untested 8x8 buttons with 16 backlit
|-
| &lt;!--Description--&gt;Novation LaunchKey Mini MK2 MKII 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 untested - 25 soft mini keys - 2 rotary wheels lhs - 
|-
| &lt;!--Description--&gt;Novation LaunchKey 25 37 49 61 88 MK3 MKIII 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2020 USB class compliant choice - full keys - 
|-
| &lt;!--Description--&gt;Novation LaunchKey Mini MK3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2023 untested - 25 soft mini keys - 2 sliders lhs -  
|-
| &lt;!--Description--&gt;Novation 61SL Mk3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; midi keyboard controller 
|-
| &lt;!--Description--&gt;Nymphes Dreadbox 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt; 6 voice analog synth
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| CAMD
| Opinion 
|-
| &lt;!--Description--&gt;Oberheim MC 2000 EX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2015 88 keys fully weighted - very heavy - 
|-
| &lt;!--Description--&gt;PreSonus ATOM SQ Hybrid MIDI Keyboard/Pad
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;[https://polyend.com/tracker/ Polyend Tracker]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Roland ED PC-300
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2002 USB MIDI keyboard controller 49-key
|-
| &lt;!--Description--&gt;Roland EDIROL PCR-M30 PCR-M50 PCR-M80 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2005 
|-
| &lt;!--Description--&gt;Roland Edirol PCR-30 PCR-50 PCR-80
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2007 untested 32 key - 
|-
| &lt;!--Description--&gt;Roland PC-50 PC-80
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2007 
|-
| &lt;!--Description--&gt;Roland PCR-500 PCR-800
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 61 velocity-sensitive keys with aftertouch 
|-
| &lt;!--Description--&gt;Roland A-88 a-49
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 USB port - weighted keys velocity no aftertouch - class compliant with press FUNCTION so it is lit. Press the key labelled &quot;ADV.&quot;, Press the &quot;+&quot; button so it is lit - 
|-
| &lt;!--Description--&gt;Roland PC-200 mkII
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 some had fatar keys 
|-
| &lt;!--Description--&gt;Roland MC-707 Groovebox
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2015 
|-
| &lt;!--Description--&gt;Roland MC-101 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2015 untested 
|-
| &lt;!--Description--&gt;Roland A-500 A500Pro
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 
|-
| &lt;!--Description--&gt;Roland A-300 A300Pro
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 
|-
| &lt;!--Description--&gt;Roland JUNO DS, FA, Fantom, JUPITER X / Xm 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 (be sure that USB driver is set to &quot;Generic&quot; - requires device rebooting) 
|-
| &lt;!--Description--&gt;Roland A-88 a-49 MKii MK2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2020 expensive with USB-c port - hammer-action keyboard weighted keys - Class-compliant if  USB-C enables bus power - MIDI 2.0 later - 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;ROLI Seaboard RISE 25 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; midi keyboard controller 
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| CAMD
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; midi keyboard controller 
|-
| &lt;!--Description--&gt;Samson Graphite 49 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Samson Carbon 49 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Sequential TAKE 5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Studiologic VMK-161 and VMK-161 Plus Organ version 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }} 
| &lt;!--Opinion--&gt;TP-8O action is the unweighted, organ-style waterfall keybed - usb midi in out - 9v psu - 
|-
| &lt;!--Description--&gt;Studiologic SL990XP midi controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Studiologic VMK176 Plus
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }} 
| &lt;!--Opinion--&gt;USB and midi connectivity
|-
| &lt;!--Description--&gt;Studiologic SL880 midi controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Studiologic SL73 SL88 Studio midi controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; hammer-action Fatar TP semi-weighted keys 
|-
| &lt;!--Description--&gt;Studiologic Numa Organ 2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; 73 key TP-8O action is the unweighted, organ-style waterfall keybed used in nearly all clonewheels 
|-
| &lt;!--Description--&gt;Studiologic Numacompact 2/2x, Numa X Piano
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;SubZero CommandKey49 CommandKey25 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;SubZero SZ-MiniCommand Mini-Command USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;SubZero SPC61 MIDI Controller
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; bus powered - 5 octave 
|-
| &lt;!--Description--&gt;SubZero ControlKey49S 49 Key Slim MIDI Controller Keyboard
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Synido TempoKey K25
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2023 25 mini keys - usb-c powered 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{maybe| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Worlde Panda 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; midi keyboard controller 
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| CAMD
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Yamaha KX8 KX49 KX61 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2008 not compliant 
|-
| &lt;!--Description--&gt;Yamaha CMC-PD
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2010 
|-
| &lt;!--Description--&gt;Yamaha 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 not class compliant 
|-
| &lt;!--Description--&gt;Yamaha P45B P-45 Digital Piano 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2011 not compliant 
|-
| &lt;!--Description--&gt;Yamaha P-115 midi controller  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 untested weighted keys - USB midi port 
|-
| &lt;!--Description--&gt;Yamaha MX49 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2020 should compliant untested 
|-
| &lt;!--Description--&gt;Yamaha Montage, CP73/88, YC, MODX
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  midi keyboard controller 
|-
| &lt;!--Description--&gt;Yamaha PSR-E353, PSR-E443
PSR-S670, PSR-S770, PSR-S970, PSR-A3000, TYROS-5
NP-12, NP-32
DGX-650, DGX-660
P-105, P-115, P-255
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Yamaha MX49 II V2 Black Blue 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2023 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  midi keyboard controller 
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| CAMD
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;DJM V10
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt; dj 
|-
| &lt;!--Description--&gt;Native Instruments Kontrol DJ Pro midi controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; detected but untested 
|-
| &lt;!--Description--&gt;Numark Mixtrack Pro II USB DJ Controller Djay 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;older generation pioneer DDJ-SX2 dj 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|}


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;20%&quot; | Description 
! width=&quot;10%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;10%&quot; |CAMD
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;Alyseum AL-22 AL22c  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Alyseum AL-88 Schneidersladen AL88c 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Alyseum U3-88c Midi Interface
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; no CopperLan support Midi network using a UTP Ethernet patch cable) 
|-
| &lt;!--Description--&gt;Behringer BCF2000 midi interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;[http://www.behringer.com/EN/home.aspx Behringer] BCR2000 1in 2out
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Behringer B-CONTROL DEEJAY BCD3000 DJ Mixer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Behringer UMD404 UMD202 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Creative EMU 0404/USB midi interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2006 
|-
| &lt;!--Description--&gt;DigiDesign / Focusrite Command 8 Control Surface
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2005 supports MIDI continuous controller (CC) and note data. SysEx dumping and loading is also supported  
|-
| &lt;!--Description--&gt;Digidesign Digi 002
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2006   firewire only 
|-
| &lt;!--Description--&gt;Digidesign Digi 003
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2009   firewire only 
|-
| &lt;!--Description--&gt;emagic m4 2x4 AMT8 Unitor 8 Mk2  8x8 
| &lt;!--Vendor ID--&gt;0x00d0
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;0x010 0x0103
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2000 offers MTS (Midi Time Stamping) - 12v 2a psu centre pos - usb mini with rs232 and rs422 serial ports - 16 channels (8-in / 8-out), this rack-mountable unit - 
|-
| &lt;!--Description--&gt;Evolution U-Control UC-16 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| detected}}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Focusrite Saffire 6 USB 1.1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Guillemot Maxi Studio ISIS Vintage Sound Card MIDI Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|dedicated driver}}
| &lt;!--Opinion--&gt;1998 
|-
| &lt;!--Description--&gt;[http://www.ucapps.de/mbhp_usb.html MidiBox] Hardware Platform USB Module
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2001 
|-
| &lt;!--Description--&gt;Mackie Control Universal Pro XT with One Two Extenders 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2008 not compliant, 
|-
| &lt;!--Description--&gt;M-Audio Audiophile USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2003 not compliant, 
|-
| &lt;!--Description--&gt;M-Audio Midisport UNO old version 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2004 not compliant, 
|-
| &lt;!--Description--&gt;M-Audio MidiMan 1x1 midi interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2004  [http://sourceforge.net/projects/linux-hotplug/ firmware update]
|-
| &lt;!--Description--&gt;M-Audio Midisport 2x2 yellowy green blue, green or silver chassis plastic box 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|MIDISPORT 2x2 or 4x4 interfaces from previous production series (blue, green or silver chassis) are not class-compliant}}
| &lt;!--Opinion--&gt;2004 
|-
| &lt;!--Description--&gt;MAudio Audiosport Quattro USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|dedicated driver}}
| &lt;!--Opinion--&gt;2004 not usb compliant as [http://usb-midi-fw.sourceforge.net/ firmware required and that is buggy], 
|-
| &lt;!--Description--&gt;M-Audio UC-33
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2004 not compliant, 
|-
| &lt;!--Description--&gt;M-Audio Midisport 1x1 2x2 4x4 Anniversary Edition, black box 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 maybe class compliant, 
|-
| &lt;!--Description--&gt;Mooer Steep II Multi-Platform USB Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;[http://www.amiga.org/forums/showthread.php?t=52920 Mark of the Unicorn Motu Fastlane] 2x2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|[http://www.amiga.org/forums/showpost.php?p=560852&amp;postcount=8 not working on OS4]}} 
| &lt;!--Opinion--&gt; not class compliant, 
|-
| &lt;!--Description--&gt;Motu Micro Lite 1x1 and MOTU microlite 5x5 USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|dedicated driver}}
| &lt;!--Opinion--&gt; good unit but poor just plug in support and not class compliant - USB2 usb-b - 
|-
| &lt;!--Description--&gt;Motu MIDI Express 128 8x8
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|dedicated driver}}
| &lt;!--Opinion--&gt;poor support serial port only - offers MTS (Midi Time Stamping) A serial port based MIDI interface or a USB interface without MTS will have a MIDI slop of up to 2ms on record and playback. MTS provides accuracy for record and playback to around .3ms - five times more accurate than serial or non-MTS.&quot; 
|-
| &lt;!--Description--&gt;MOTU.com MIDI Express XT 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|dedicated driver}}
| &lt;!--Opinion--&gt;2008 for many USB should have octocoupled connection to reduce groundloop humm, usually the timing is off 
|-
| &lt;!--Description--&gt;MOTU MIDI Timepiece AV 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|dedicated driver}}
| &lt;!--Opinion--&gt; not class compliant is one of the best multi-port MIDI interfaces ever made as USB model connects to the computer as an 8x16 interface
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Native Instruments GmbH Audio 8 DJ, 4 DJ, 2 DJ
| &lt;!--Vendor ID--&gt;0x17CC
| &lt;!--Product ID--&gt;0x
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no|needs dedicated driver}}
| &lt;!--Opinion--&gt;2006 not class compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Qcon 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Roland Edirol UA-100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|did not match to camdusbmidi.class USB audio midi with onboard DSP}}
| &lt;!--Opinion--&gt;1998 
|-
| &lt;!--Description--&gt;Roland Corp Edirol UM-2 
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt;0x0005
| &lt;!--Revision--&gt;0200
| &lt;!--CAMD--&gt;{{no|is not bound via camdusbmidi.class }}
| &lt;!--Opinion--&gt;1999 not bound to any midi class - 2x2 - tested Aros One USb 2.4 
|-
| &lt;!--Description--&gt;Roland Edirol UA-100G 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|detected but not working}} 
| &lt;!--Opinion--&gt;1999 USB audio midi with onboard DSP 
|-
| &lt;!--Description--&gt;Roland Edirol UM-880 8x8 midi interface 
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|detected but not working}} 
| &lt;!--Opinion--&gt;2000 under poseidon but could work with run &gt;nil: c:midithru out.0 &quot;EDIROL UM-880.out.2&quot;
|-
| &lt;!--Description--&gt;Roland Edirol UM-1 blue plastic 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{Unk| bound??? via camdusbmidi.class - untested midi in out}}
| &lt;!--Opinion--&gt;2000 UM-1 -  1-in/1-out (16 channels) 
|-
| &lt;!--Description--&gt;Roland Edirol UM-1S
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|not working}} 
| &lt;!--Opinion--&gt;2000 1-in/1-out (16 channels)
|-
| &lt;!--Description--&gt;Roland Edirol UM-2E
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|not working}} 
| &lt;!--Opinion--&gt;2000 
|-
| &lt;!--Description--&gt;Roland Edirol UM550
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2001 
|-
| &lt;!--Description--&gt;Roland Edirol UM-1X midi interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|do not have the Advanced Driver Switch on them}}
| &lt;!--Opinion--&gt;2001 
|-
| &lt;!--Description--&gt;Roland Edirol UM-1SX
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt;0x0052
| &lt;!--Revision--&gt;0200
| &lt;!--CAMD--&gt;{{No|do not have the Advanced Driver Switch on them}}
| &lt;!--Opinion--&gt;2003 
|-
| &lt;!--Description--&gt;Roland Edirol Cakewalk UM-2C - 2x2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2003 
|-
| &lt;!--Description--&gt;Roland Edirol Cakewalk UM-1G 1x1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2004 
|-
| &lt;!--Description--&gt;Roland Edirol Cakewalk UM-2G 2x2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2004 
|-
| &lt;!--Description--&gt;[https://github.com/spotify/linux/blob/master/sound/usb/usbquirks.h Roland Edirol UA20 UA-20] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|not working}} 
| &lt;!--Opinion--&gt;2004 
|-
| &lt;!--Description--&gt;Roland UM-1EX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2005
|-
| &lt;!--Description--&gt;Roland Edirol UM-2EX 2x2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2005  adds a second MIDI OUT
|-
| &lt;!--Description--&gt;Roland Cakewalk UM-3G - 3x3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2006 
|-
| &lt;!--Description--&gt;Roland Cakewalk ua-25excw 1x1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|detected but not working}} 
| &lt;!--Opinion--&gt;2009 not class compliant mode 
|-
| &lt;!--Description--&gt;[https://alsa.opensrc.org/Edirol_UA-25EX Roland Edirol UA55 UA-55 Cakewalk UA25 EX] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|detected but not working}} 
| &lt;!--Opinion--&gt;2011 not usb compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Sonuus B2M Bass MIDI Interface
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Sonuus G2M
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Steinberg CMC Series 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Subzero SZ-MB44 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Swisssonic MIDI1x1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt;2012 AmigaOS there is no output at midichannel one and two but if play a midi file there is only output on some channels and if pressed stop the prog freezes or the whole system crashes
|-
| &lt;!--Description--&gt;Teac Tascam US-428 US-422 midi interface 
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt; 2000 not compatible 
|-
| &lt;!--Description--&gt;Teac Tascam [http://web.archive.org/web/*/http://www.tascam.com/Products/US-224.html US-224]
| &lt;!--Vendor ID--&gt;0x1604
| &lt;!--Product ID--&gt;0x8004
| &lt;!--Revision--&gt;0100
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt; 2002 does not bind to any class
|-
| &lt;!--Description--&gt;Teac Corp Tascam US-1x2
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }} 
| &lt;!--Opinion--&gt;2002 
|-
| &lt;!--Description--&gt;Teac Tascam US-122 MKII midi interface 
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt;0x8021
| &lt;!--Revision--&gt;0100
| &lt;!--CAMD--&gt;{{No|not detected / binding to camdusbmidi.class on AROS 2.4 usb }} 
| &lt;!--Opinion--&gt;2004 detected but not working 2-in/2-out USB two XLR microphone preamps with phantom power for condenser microphones 
|-
| &lt;!--Description--&gt;Teac Tascam US-200 US-400 US-600 US-800 US-1200 US-1800 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|no driver}}
| &lt;!--Opinion--&gt;2010 may not be totally usb compliant 
|-
| &lt;!--Description--&gt;Yamaha UX-16
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|no driver}}
| &lt;!--Opinion--&gt;2010 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| CAMD
| Opinion 
|-
| &lt;!--Description--&gt;Akai EIE and Pro version midi interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2011 dc 6v power - 3 USB hubs, midi in out , 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Alesis I/O2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2007 powered USB hub required, not compliant 
|-
| &lt;!--Description--&gt;Alesis IO2 Express 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 usb compliant?
|-
| &lt;!--Description--&gt;Alesis IO4 Express 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 
|-
| &lt;!--Description--&gt;Behringer XTouch 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; psu needed 
|-
| &lt;!--Description--&gt;Behringer X-Touch Compact
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 maybe usb compliant?
|-
| &lt;!--Description--&gt;Behringer X-Touch Mini
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 maybe usb compliant?,  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Behringer U-Phoria UMD404HD UMD202HD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe class compliant - volume low, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;CME U2 MIDI Pro 1x1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; current model 
|-
| Creative EMU XMIDI 1X1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 early versions with sysex checksum errors 
|-
| &lt;!--Description--&gt;Creative E-MU Xmidi 1x1 Tab (V3) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 tab version class compliant but report that when transferring 'System Exclusive' messages (SysEx) the unit could not handle the highest data rate leading to data corruption 
|-
| Creative EMU XMIDI 2x2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 sysex errors 
|-
| &lt;!--Description--&gt;Digidesign Mbox 2 Mini now Avid 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2005 USB powered but not compliant 
|-
| &lt;!--Description--&gt;Digidesign Mbox II Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt;2006 USB powered but not compliant 
|-
| &lt;!--Description--&gt;Engl Z7 MIDI Interface (E660/E610/E360/E930)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; guitar?
|-
| &lt;!--Description--&gt;Elektron TurboMidi TM-1 1in 1out
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;ESI MidiTerminal M4U 4x4 midi interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;supposedly class compliant - USB bus powered - 
|-
| &lt;!--Description--&gt;ESI MidiTerminal M8U 8x8
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;ESI MidiTerminal M4U XL 4x4
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; ploytec chipset 
|-
| &lt;!--Description--&gt;ESI MidiTerminal M8U XL 8x8
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; no hardware routing e.g. x on input 5 to synth y on output 7 - ploytec chipset 
|-
| &lt;!--Description--&gt;ESI MidiMate 1x1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; supposedly class compliant - USB bus powered 
|-
| &lt;!--Description--&gt;ESI MidiMate II 2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;ESI ROM I/O
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2005 romio version 
|-
| &lt;!--Description--&gt;ESI M4U XT
| &lt;!--Vendor ID--&gt;0x2573
| &lt;!--Product ID--&gt;0x0002
| &lt;!--Revision--&gt;0100
| &lt;!--CAMD--&gt;{{Maybe|is bound via camdusbmidi.class AROS One 2.4  - untested midi in out}}
| &lt;!--Opinion--&gt;2010  - 
|-
| &lt;!--Description--&gt;ESI M8U XT 8in 8out
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 discontinued 2018 
|-
| &lt;!--Description--&gt;ESI M8UEX USB3.0
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 current model 
|-
| &lt;!--Description--&gt;ESI M4U eX
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 current model 
|-
| &lt;!--Description--&gt;ESI MidiMate eX midi interface 1x1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 curent model, well liked and might class compliant?? 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;icon midiport 2x2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;iCON CubeMi 3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; class compliant? 
|-
| &lt;!--Description--&gt;iConnectivity 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;iConnectivity mio 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 class compliant but reported issues with sending System Exclusive (SysEx) MIDI messages and MIDI signals getting cut off 
|-
| &lt;!--Description--&gt; iConnectMidi interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 
|-
| &lt;!--Description--&gt;iCM2 iCM4 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2012 
|-
| &lt;!--Description--&gt;iConnectivity iConnectMIDI4+ L
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 class compliant?? 
|-
| &lt;!--Description--&gt;iConnectivity MioXL 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;IK Multimedia iRig MIDI 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; class compliant 
|-
| &lt;!--Description--&gt;iRig Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Kenton 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Kenton Electronics pro solo mk2 midi to cv converter
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Kenton Midi Thru-25 5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Keytech MT18E 8 Way Midi Thru box 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; 9 to 12v psu required 
|-
| &lt;!--Description--&gt;MidiPlus Midi 2x2 midi interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;MidiPlus Midi 4x4 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; supposedly class compliant - USB bus powered 
|-
| &lt;!--Description--&gt;MidiTech MIT-00151 Midiface 4x4
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;MidiTech Midiface 4x4 8x8 16x16 thru merge 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Miditech Midilink mini 1x1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;M-Audio Midisport UNO only if box is labeled Class Compliant and latest MIDISPORT 1x1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;M-Audio Fast Track Ultra (6 in 6 out) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 not usb compliant, - 
|-
| &lt;!--Description--&gt;M-Audio Midiman Midisport 2x2 Anniversary Edition [https://gearspace.com/board/electronic-music-instruments-and-electronic-music-production/1133862-why-there-hardly-any-midi-interfaces.html not stable enough] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2009 USB2 usb-b - does not need firmware and supposedly plug and play - 
|-
| &lt;!--Description--&gt;M-Audio Midisport 4x4 Anniversary Edition
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; rumored does not need firmware - supposedly plug and play -  issues with its firmware for some and lacks configurable routing
|-
| &lt;!--Description--&gt;Maudio Fast Track Ultra 8R 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Native Instruments Komplete Audio 6 Mk1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2011 maybe usb compliant but bus powered, 
|-
| &lt;!--Description--&gt;Nektar Midiflex 4
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|untested}}
| &lt;!--Opinion--&gt;2015 class compliant and usb-b powered - used as a 1 in / 3 out, 2 in / 2 out or 4 out 5pin sockets - 
|-
| &lt;!--Description--&gt;Neusonik IM-One 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Peavey Xport
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; guitars only 
|-
| &lt;!--Description--&gt;Roland UM-ONE UM-1 mk2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 USB class compliant if switch to TAB for class compliant mode rather than the COMPUTER mode 
|-
| &lt;!--Description--&gt;Squarp Hermid 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Steinberg Midex 8x8 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; class compliant?  supporting MIDI Time Stamping protocol
|-
| &lt;!--Description--&gt;Swissonic MidiConnect 2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Tapco LiNK.midi USB 4x4 (Loud technologies) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no|dedicated driver}}
| &lt;!--Opinion--&gt;2005 
|-
| &lt;!--Description--&gt;Teac Corp Tascam US-2x2
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{no| }}
| &lt;!--Opinion--&gt; 2014 5v dc power, midi out in, 
|-
| &lt;!--Description--&gt;Teac Corp Tascam US-4x4
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt; 
|-
| &lt;!--Description--&gt;Teac Tascam US-16x08 US-20x20
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No| }}
| &lt;!--Opinion--&gt; 
|-
| &lt;!--Description--&gt;Zoom U-24
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  midi to 5pin interface 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  midi to 5pin interface 
|-
| &lt;!--Description--&gt;Unbranded cable 
| 0x552d
| 0x4348
| F110 
| &lt;!--CAMD--&gt;{{Maybe|detected but no usb driver in devs/midi for camd to use}}
| &lt;!--Opinion--&gt;detected but not working the USB-MIDI conversion functionality of the cheapo USB MIDI &quot;cable&quot; interface is simply lacking, possibly being incapable of handling MIDI strings longer than 3 bytes long SysEx strings (e.g. SysEx dumps) - tested in Icaros 2.3 - 
|-
| &lt;!--Description--&gt;USB2.0-MIDI Unbranded cable with clear braided underneath leads 
| &lt;!--Vendor ID--&gt;0x1A86
| &lt;!--Product ID--&gt;0x752D 
| &lt;!--Revision--&gt;0254 
| &lt;!--CAMD--&gt;{{Maybe|detected binding to camdusbmidi.class but untested midi in / out}}
| &lt;!--Opinion--&gt;untested but better to get a branded version - tested AROS One 2.4 usb
|-
| &lt;!--Description--&gt;LogiLink USB to Midi In-Out 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk|}}
| &lt;!--Opinion--&gt;untested cheap cable version but issues with latency on other systems 
|-
| &lt;!--Description--&gt; gm5 USB midi chip  DIY option only
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Doremidi LEKATO MIDI USB C Interface 1x1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;Thomann Midi USB 1x1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;   Prodipe made 
|-
| &lt;!--Description--&gt;Prodipe MIDI 1i/1o 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  usb to 5pin midi interface 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|}


Classic 5pin DIN controllers for above interfaces 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;20%&quot; | Description 
! width=&quot;10%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;10%&quot; |CAMD
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;Akai s5000 s6000
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  midi digital samplers 
|-
| &lt;!--Description--&gt;Akai AX80 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Casio CZ-5000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Casio CZ-3000 CZ-1000 CZ-101 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Cheetah MS6 midi controller 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{No|untested}}
| &lt;!--Opinion--&gt;2000 multi-timbral, six-voice (twelve-oscillator), analogue synthesiser module is loaded with CEM 3396s 
|-
| &lt;!--Description--&gt;Ensoniq ESQ1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Integra 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Korg Wavestation Ex A/D SR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;1986 ex has piano and drum sounds 
|-
| &lt;!--Description--&gt;Korg DW-8000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Korg DW-6000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Korg Poly 800 MK1 Poly-800ii 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  all plastic and can run on batteries - 49 keys non-velocity dco synt analogue filter 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Roland D-50
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|1987 untested greater concern would be moisture and wear}}
|-
| &lt;!--Description--&gt;Roland A50 (76) A80 (88) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|1989 untested}}
|-
| &lt;!--Description--&gt;ROLAND JUNO-D
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Roland Juno 106 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;80s kx73 or kx88 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Roland ED PC-160A PC-180A 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}} legacy DIN5 MIDI port only - 6 AA batteries or 9v psu - One regular source of failure for me were emty batteries (even with red control light still active). Another source was a bad MIDI cable - unplug then re-plug the USB cable while it is powered the device might reconnect 
|-
| &lt;!--Description--&gt;Roland M1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Roland S-550 S-760 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt; digital samplers kontakt replaced these? 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Yamaha DX7 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;1983 12bit 
|-
| &lt;!--Description--&gt;Yamaha DX7S DX72IID DX7IIFD 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;1987 16bit versions 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--CAMD--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
|}


The MIDI standard was published in August 1983. The inventors, Kakehashi and Smith finally received a Technical Grammy Award in 2013 for their work. 

The MIDI files that contained just the note data, velocity and timing meant you could transfer an entire studio session from one place to another on one floppy disk and it could control all the synths and drum samplers. Pass-thru meant that one computer could run an entire bands worth of instruments. 

It's bulletproof too. MIDI never goes wrong, it's always a bug in software that causes any issue - you can absolutely rely on it to go gigging with, take your synths, controllers and computers and not crash an entire gig at your 100,000 person venue. 

The MIDI hardware specification is very simple (voltage, polarity, screening, protection and a fast enough opto-isolator), it assumes that the data it sends and receives between MIDI devices is to the MIDI data standard and just passes it on. The microprocessor in the hardware does all the work.

The minimum for a computer/MIDI interface is that it meets the MIDI hardware specification. It is attached to the computer bus and handles the electrical conversions required. To meet the MIDI hardware specification, to be class compliant as a USB device all it has to do is report itself properly when plugged in.

The other half of the equation is the MIDI data standard, and for a computer MIDI interface the main issue is the speed of data transmission. The bus speed of the computer is faster than the speed of the MIDI standard so it can generate and send MIDI data faster than a MIDI device can receive it. The MIDI standards have nothing to say on that bottleneck at all. MIDI was designed to be very simple and very open, it just defines a standard for the messages and leaves it up to manufacturers to implement them in the way they want. That's what makes it so powerful a tool, and also what makes it so confusing and frustrating at times.

For midi, the hardware/software combination at various connection points handles the translation to/from midi (or other protocols). Drivers would be needed for midi, including clock and SysEx signal (actually claiming to handle ALL midi quirks transparently

All the important MIDI data types can be sent (CC, NRPN, RPN, MMC, Note On/Off, program change)

There is no official way to solve the data bottleneck. Early software sequencers and librarians tried to solve it by having an option to buffer SYSEX data in software and transmit it at the MIDI data rate. The downside is that hogs the bus and can hit computer performance. Interface manufacturers would add a hardware buffer which would take all the MIDI data from the PC bus and feed it into the MIDI at the slower data rate, but that added cost and created timing issues.

Things have moved on since then, but the principles remain the same. You can buffer in the hardware or in software, whether that is in the application or the interface driver. SYSEX will work perfectly well with that budget cable if your software handles the buffering. And while the cables with hardware buffers make SYSEX easier, they still have potential problems because of the limitations of the MIDI data rate. Your MIDI clock doesn't like being interrupted with a big program dump 

The serial / parallel ports were a direct connection, so faster. Now, everything in the computer is virtual and the only thing connected to the hardware is the kernel, hence everything is by default bottlenecked and jittery, regardless of which connection. So by the time the interface gets the information it's already too late. 

Ethernet network cable to transport MIDI over large distances, connect 2 MIDI In and 2 MIDI Out ports to patch, remap, filter and merge MIDI flows on a fine channel basis for tight MIDI throughput, latency and jitter 

Possibilities for DAWs of the future including a kind of sync reference for timing reference which an interface could sync to, hence all the timings then would be locked between the grid on the DAW screen and the MIDI info. 

Preemptible, low latency and accuracy are essential for good communication.  

One of the first things you need to do, is make sure your MIDI software sets the interface to the same MIDI channel as your keyboard (usually 1) 


Do you want to send just your master keyboard to other synths or to be able to use any keyboard with any synth?

1st option is relatively simple. Just need to send midi from your master keyboard into a midi splitter that redistributes the signal onto your synths. Each synth will be set up to receive midi on a specific channel so the only challenge is to find a way to select to which channel you are sending midi. Some master keyboards can do that although not many that have a dedicated knob or switch on the panel and most require a bit of menu diving. Could use a midi box that offers channel selection but usually this is not very workflow friendly. The software route would require using the mouse. 

2nd option is a bit more complex but superior workflow by sending midi messages into a merge box, from there into a hardware sequencer that allows to select midi channel, then on to a midi interface that distributes the signal to the synths. 

Master keyboard MIDI-in to computer. External hardware sampler MIDI-out from computer. Audio-out from sampler to audio-in on computer/device. 


Blue Ribbon Soundworks Bars &amp; Pipes Professional (1993/4) 

GM (1984), GS (1987), XG level 1-3 (1994-1997), GM level 2 (1999) 	

GM GM1 imposes several requirements beyond the MIDI 1.0 specification. While MIDI 1.0 by itself provides a communication protocol which ensures that different instruments can interoperate at a fundamental level e.g sound modules. GM goes further in two ways. First, GM requires that all compliant MIDI instruments meet a certain minimal set of features, such as being able to play at least 24 notes simultaneously (polyphony). Second, GM attaches specific interpretations to many parameters and control messages which were left unspecified in the MIDI 1.0 specification. A minimum of 128 MIDI Program Numbers (conforming to the GM 1 Instrument Patch Map) and 47 percussion sounds (conforming to the GM 1 Percussion Key Map). Support for controller number 1, 7, 10, 11, 64, 100, 101, 121 and 123; support for channel pressure and pitch bend controllers. 

General MIDI Level 2 or GM2 is a specification for synthesizers which defines several requirements beyond the MIDI standard and is based on General MIDI (GM) and Roland GS extensions. It was adopted in 1999 by the MIDI Manufacturers Association (MMA).

* Number of Notes: 32 simultaneous notes
* MIDI Channels: 16
* Simultaneous Melodic Instruments – up to 16 (all Channels)
* Simultaneous Percussion Kits – up to 2 (Channel 10/11)

Program and bank change events
General MIDI 2 compatible synthesizers access all of the 256 instruments by setting cc#0 (Bank Select MSB) to 121 and using cc#32 (Bank Select LSB) to select the variation bank before a Program Change. Variation bank 0 contains the full GM (General MIDI 1) sound set. Variations using other bank numbers are new to General MIDI 2, and correspond to variation sounds introduced in Roland GS. 


[https://www.youtube.com/watch?v=CluuHrr7HG4 Major WWHWWWH, Minor WHWWHWW scale], [https://www.youtube.com/watch?v=Jjm7Ti-iwz0 Chords], 


==usb audio==

 AROS currently does not support natively any USB audio interface for recording audio 

USB audio is only available for limited Amiga like OSs, independent of the USB protocol version USB1.x USB2, USB3.x, which are not backwards compatible. 

*Introduced 2000 and from 2014 USB Audio 1 UAC1 16bit 44.1kHz
*Introduced 2006 and from 2014 USB Audio 2 [https://www.usb.org/document-library/usb-device-class-definition-audio-devices-release-20-errata-and-ecn-through-april UAC2] 24bit 192kHz
*Introduced 2016 and from 2024 USB Audio 3 [https://www.usb.org/documents UAC3] 32bit 384kHz 

USB group decided to rewrite the audio standard, so [https://os4depot.net/?function=showfile&amp;file=audio/record/usbaudio2.lha UAC2] and [https://archive.fosdem.org/2019/schedule/event/linux_and_usb_audio_class_3/attachments/slides/3345/export/events/attachments/linux_and_usb_audio_class_3/slides/3345/Linux_and_USB_Audio_Class_3___FOSDEM_2019.pdf UAC3]. They added clock selection and control, timing domains and others. Part of the changes included changing many of the descriptors that an audio device uses to describe itself to the machine. 

PsdErrorlog/PsdDevlister? The AHI driver generated only supports mono/stereo at any bit rates between 8 and 32 bit per sample, but not multichannel modes and only rates up to 65KHz (because AHI uses a 16-bit word for frequencies). If the soundcard does not offer such a PCM 8-32 bit mode at frequencies lower than 65 KHz, there's nothing much that can be done about it on the computer side other than revising and expanding the AHI standard. Most cheap USB soundcards do though. 

AHI does not support six channel playback. It only supports mono, stereo and multichannel (8 channels). Due to the multichannel mode not being used by any application so far, the usbaudio.class does not support multichannel playback, especially not &quot;upchannelling&quot; stereo to six or more channels. If this USB device does not support a two channel mode, you can't use it under AHI.

Untested but most likely to work, at least 2 mic inputs (low impedance) &amp; instruments (high impedance) and made in the last 10 years 
*[https://www.youtube.com/watch?v=gMuA-2FbJxE Entry level &lt;100Euro]   BOMGE U202, Behringer UMC, Presonus Studio, 
*[ Next tier &lt;200Euro]   Audient iD, Solid SSL2 and SSL2+, Lewitt, Focusrite Scarlett, Arturia MiniFuse, 
*[ Prosumer &lt;300Euro]   Focusrite Clarett+, 
*[ Professional &lt;500Euro]   RME Babyface, 
*[ Studio &gt;500Euros]    

Bands may need 4 or more mic inputs 

[http://forum.xda-developers.com/showthread.php?p=38364030 XDA Forum thread],

&lt;pre&gt;
                                            &lt;- Computer 
                                            &lt;- Mobile Phone / Tablet (OTG)
                                            &lt;- Digital Cameras 
                            &lt;- Video        &lt;- Webcams 

Base Computer &lt;-&gt; OBS like  &lt;- Audio Mixer  &lt;- Microphone(s) 

                            -&gt; Internet     -&gt; Youtube &amp; Chat 

&lt;/pre&gt;

USB AUDIO CARDS - UAC Compliant 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;20%&quot; |Description 
! width=&quot;10%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;10%&quot; |Playback
! width=&quot;10%&quot; |Records 
! width=&quot;30%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Antelope Galaxy 64 Synergy Core
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; not compliant and a high-end 64-channel AD/DA converter HDX, Dante connectivity and a Thunderbolt Audio interface 
|-
| &lt;!--Description--&gt;Antelope Galaxy 32 Synergy Core
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;may not be compliant as Antelope Audio does not provide official drivers, control software, or an Antelope Launcher 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Arturia Mini Fuse 1
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2021 maybe usb compliant, okay pre amp 1 combi input, cirrus logic cs4272 ad converter, 
|-
| &lt;!--Description--&gt;Arturia MiniFuse 2
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2021 maybe usb compliant usb-c with usb2.0, okay pre amps with good dynamic range 110dB, cirrus logic cs4272 ad converter, two combi inputs for mic, line or guitar, 
|-
| &lt;!--Description--&gt;Arturia MiniFuse 4 
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2022 maybe usb compliant, okay 110dB dynamic range, -129dB EIN, 
|-
| &lt;!--Description--&gt;Arturia AudioFuse 16Rig 
| &lt;!--Vendor ID--&gt;0x1C75
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2023 maybe usb compliant, good 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Audient iD44 mk1 mki 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2018 maybe usb compliant, good, 
|-
| &lt;!--Description--&gt;Audient evo4 EVO8 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2020 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Audient iD4 mk2 mkII
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2022 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Audient id14 mk2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2022 maybe usb compliant, good, 
|-
| &lt;!--Description--&gt;Audient iD24 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2023 maybe usb compliant and usb-c bus powered, good, , 0-in/14-out audio interface with ADAT expandability, balanced inserts
|-
| &lt;!--Description--&gt;Audient iD44 Mk2 Mkii 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2022 maybe usb compliant, good, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Behringer U-PHORIA UMC22 
| &lt;!--Vendor ID--&gt;0x1397
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 maybe usb compliant, okay, midas pre-amps
|-
| &lt;!--Description--&gt;Behringer U-PHORIA UMC202HD 
| &lt;!--Vendor ID--&gt;0x1397
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 maybe usb compliant, okay, midas pre-amps ein -129 dBu, 24bit ADC, 
|-
| &lt;!--Description--&gt;Behringer U-PHORIA UMC404HD 
| &lt;!--Vendor ID--&gt;0x1397
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 maybe usb compliant, okay, midas pre-amps, 24bit adc, 
|-
| &lt;!--Description--&gt;Behringer U-PHORIA UMC204HD 192 Empower Tribe 
| &lt;!--Vendor ID--&gt;0x1397
| &lt;!--Product ID--&gt;0x0508
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2015 maybe usb compliant, okay, midas pre-amps
|-
| &lt;!--Description--&gt;Behringer UMC1820 
| &lt;!--Vendor ID--&gt;0x1397
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2016, bus complaint?, okay midas pre amps, adc, 
|-
| &lt;!--Description--&gt;Behringer U-PHORIA UM2 
| &lt;!--Vendor ID--&gt;0x1397
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 maybe usb compliant, poor zenyx pre-amps with high noise floor, plastic build no rf shielding, latency issues, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Focusrite Saffire 6 USB 1.1
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 maybe usb compliant, , , midi, strictly NEC USB 2.0, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett 8i6 Gen 1 MOSC0001 
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 maybe usb compliant, but 
|-
| &lt;!--Description--&gt;Focusrite Scarlett 2i2 Gen 1 MOSC0003 
*TP1 - 3.3V, tested ok
*TP2 - U4 control signal, 3.3V present at all time.
*TP4 - Ground
*TP6 - 48V, tested ok
*TP7 - Ground
*TP8 - Ground
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 usually avoid early Gen 1, 
|-
| &lt;!--Description--&gt;[https://khronscave.blogspot.com/2021/08/75-focusrite-scarlett-2i4-1st-gen.html Focusrite Scarlet 2i4 Gen 1 (slide toggles) MOSC0004] 
*TP1 - 3.3V, tested 3.22v
*TP2 - U4 control signal, 3.3V present 
*TP4 - Ground
*TP6 - measure 47.72v 
* AKM 4384ET (VDD 5v)
* Cirrus Logic CS4272-CZZ (VA 4.94v/ VD 3.2v/ VL 3.2v)
* all four HC4066 (VCC 4.96v)
* XMOS XS1-L01A-TQ128-C5 (all VDD 1.08v/ all VVDIO 3.23v/ PPLAVDD 0.99v/ PCU-VDDIO 3.23v)
2i4S
*TP1 seems to be 0V
*TP2 should be 5V
*TP3 should be 
*TP6 should be 48V
*TP8 should be 3.3V
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 maybe usb compliant, pre amps JRC NJM2122 and NJM4565, [https://statics.cirrus.com/pubs/proDatasheet/CS4272_F1.pdf CS4272 adc], [https://pdf.datasheet.live/e5e5fd1c/akm.com/AK4384.pdf AK4384 output pair], Xmos XS1-L8A-64-TQ128 processor and firmware in Winbond 25X40CL 4Mbit, an SMSC Microchip USB3343 interface and a Microchip PL611 clock generator - two Intersil / Renesas ISL97519A for the phantom power rail, two OnSemi NCP1521B for the 3.3V (digital) and 1V (Xmos core) rails - 
|-
| &lt;!--Description--&gt;Focusrite iTrack Solo USB Audio Interface
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2012 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett 18i20 1st Gen MOSC00
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe usb compliant, , Cirrus CS4272, 
|-
| &lt;!--Description--&gt;[http://wiki.linuxaudio.org/wiki/current_audio_gear Focusrite ] Scarlett 4i4 Gen  MOSC00
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant, , Cirrus CS4272, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett 6i6 Gen1 MOSC00
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe usb compliant, , , 12v psu, the headphone outs mirror the outs on the back panel, so that's six independent outs. 4 independent analog output paths, plus two over spdif, 
|-
| &lt;!--Description--&gt;[https://khronscave.blogspot.com/2019/03/38-focusrite-scarlett-18i8-gen1-teardown.html Focusrite Scarlett 18i8 1st Gen MOSC0008]
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe usb compliant, JRC NJM4565 provide most of the opamps, pair of JRC NJM2122's for inputs 1 and 2, [http://www.mouser.com/ds/2/76/cs4272_f1-43250.pdf Cirrus CS4272], 12v 1a +central psu to a pair of National Semiconductor LM2672 for 3.3V rail and the +6.9V rail, Xmos XS1–L16A–128 dual-row QFN package, firmware a Winbond 25X40C 4Mbit SPI Flash and an SMSC USB3343 interface chip, the two headphone outs are completely independent so 6 independent analog output paths, plus two over spdif, 
|-
| &lt;!--Description--&gt;Focusrite Clarett+ 8Pre 
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2015 great, expensive, maybe usb compliant?  
|-
| &lt;!--Description--&gt;Focusrite Scarlett 2i2 Gen 2 (slide toggles) MOSC0006 
*TP6 should be 48V
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;0x8202
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 maybe usb compliant, USB-b bus powered, good preamps ein equivalent input noise -128 dBu, 24-bit 192kHz CS4272 as well as an additional AKM AK4384ET for the second stereo output pair, 4 screws under bottom rubber,  
|-
| &lt;!--Description--&gt;[https://khronscave.blogspot.com/2021/07/focusrite-scarlett-2i4-2nd-gen-teardown.html Focusrite Scarlett 2i4 Gen 2 (slide toggles) MOSC0014]
*TP6 should be 48V
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 maybe usb compliant, USB-b bus powered, good preamps NJM2122's, NJM4565's and CMOS switches (HEF4053 and HEF4066), CS4272 and a AKM AK4384ET, Xmos XU208-256-TQ64-C10 with firmware stored in a Macronix MX25L8006E 8Mbit flash memory, clocking by a Cirrus Logic CS2100, an MP1542 boost converter creates +6V and -6V rails, powering the opamps and the rest of the analog circuitry, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett 6i6 Gen2 MOSC0016
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 maybe usb compliant, 12v psu, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett Solo 2nd Gen MOSC0019
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 maybe usb compliant, 
|-
| &lt;!--Description--&gt;[https://khronscave.blogspot.com/2024/03/focusrite-scarlett-18i8-gen2-teardown.html Focusrite Scarlett 18i8 2nd Gen MOSC00]
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 maybe usb compliant, 12v psu, 
|-
| &lt;!--Description--&gt;Focusrite Red 16Line 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2017 may not be compliant as Focusrite provides no drivers - 64-in/64-out Pro Tools - dual Thunderbolt 3 audio interface with ultra-low latency A-D/D-A conversion - Red Evolution mic preamps
|-
| &lt;!--Description--&gt;Focusrite Scarlett Solo 3rd Gen MOSC0024
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant usb-c but usb2, preamps, ad/dc 24bit 192kHz, most Focusrite gen3 interfaces have encrypted processors, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett 18i6 Gen3 MOSC00
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant, USB2 class compliant device, but with custom mixer interface
|-
| &lt;!--Description--&gt;Focusrite Scarlett 2i2 Gen 3 (push in switches) MOSC00
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;0x8210
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant, USB-c bus powered, good preamps ein equivalent input noise -128 dBu, 24-bit 192kHz Cirrus Logic xfr002c and cs4272 chips, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett 18i20 3rd gen MOSC00
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett 18i8 3rd Gen MOSC00
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;0x8214
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant, , , no screws under the rubber pads on the bottom, 12v psu, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett Solo Studio Mk3 USB Audio Interface MOSC0030 
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2020
|-
| &lt;!--Description--&gt;Focusrite Scarlett 2i2 4th Gen USB 
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett 4i4 4th Gen USB 
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett Studio 4th Gen USB 
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett Solo 4th Gen MOSC00
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant, 
|-
| &lt;!--Description--&gt;Focusrite Scarlett 18i20 4th Gen MOSC00
| &lt;!--Vendor ID--&gt;0x1235
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 maybe usb compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;FractalAudio FM9 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 
|-
| &lt;!--Description--&gt;Fractal Audio AM4 platform 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2023 not working 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Lewitt Connect 6 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant, 
|-
| &lt;!--Description--&gt;Lewitt 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Mooer Steep II Multi-Platform USB Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Motu UltraLite AVB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; usb not compliant? 
|-
| &lt;!--Description--&gt;MOTU M2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe not usb compliant?, usb-c, good pre amps, ad/dc, 
|-
| &lt;!--Description--&gt;MOTU M4 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe not usb compliant, okay, 
|-
| &lt;!--Description--&gt;MOTU U2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  maybe not usb compliant, good but latest had hardware revision 
|-
| &lt;!--Description--&gt;MOTU UltraLite-mk3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 not usb compliant, great 
|-
| &lt;!--Description--&gt;MOTU UltraLite-mk5
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2020 not usb compliant, great 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Nuemann MT48 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; usb audio compliant, great pre-amps 
|-
| &lt;!--Description--&gt;Neumann MT48 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;neuralDSP Quad Cortex QC platform 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 cc compliant but plugins not working 
|-
| &lt;!--Description--&gt;NeuralDSP QC Lite 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 cc complaint 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Neve Genesys Black G16 G32 G64
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; not compliant - very good very expensive 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Presonus AudioBox USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 maybe not usb compliant, usb1.1 usb-b bus powered, okay pre-amps, 24bit ADC 48Khz max, 
|-
| &lt;!--Description--&gt;Presonus Audiobox 1818VSL 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 maybe not usb compliant, 
|-
| &lt;!--Description--&gt;Presonus AudioBox 44VSL
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 may not be usb compliant, 12v psu, 
|-
| &lt;!--Description--&gt;PreSonus AudioBox 22VSL
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 maybe not usb compliant, 
|-
| &lt;!--Description--&gt;|PreSonus Studio 2|4 2x2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant, usb-b, 
|-
| &lt;!--Description--&gt;|PreSonus Studio 2|6 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2017 maybe usb compliant, 
|-
| &lt;!--Description--&gt;|PreSonus Studio 6|8 USB Audio Interface
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2017 maybe compliant, needs ext psu, 
|-
| &lt;!--Description--&gt;PreSonus Studio 24c 2x2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant, usb-c, good, adc, 
|-
| &lt;!--Description--&gt;PreSonus Studio 26c 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant, usb-c, 
|-
| &lt;!--Description--&gt;PreSonus® Studio 68c
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant, usb-c, 
|-
| &lt;!--Description--&gt;PreSonus AudioBox USB 96 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2020 maybe usb compliant, high preamp noise, 
|-
| &lt;!--Description--&gt;Presonus Quantum ES2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2022 maybe usb compliant, okay, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Prism 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Prism Lyra 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe not usb compliant, great 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Platane UP1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 maybe usb compliant usb- UAC2 asynchronous protocol, 64dB Low-noise Mic amplifier, 32Bit High End ADC and DAC, 16dBu High-power ti headphone amplifier
|-
| &lt;!--Description--&gt;Platane UP2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Platane 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;RME Babyface/UC/UFX
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 maybe not usb compliant, good 
|-
| &lt;!--Description--&gt;RME Fireface UCX
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2012 might be able to put into class compliant cc although a firewire device, pre amps, adc,  
|-
| &lt;!--Description--&gt;RME Babyface Pro FS  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe not usb compliant, good 
|-
| &lt;!--Description--&gt;RME Fireface UCX II
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2021 might be class compliant usb-b, pre amps, adc,  
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Solid State Logic SSL2 SSL2+ Mk1 1st Gen 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2020 maybe usb compliant, good, adc, 
|-
| &lt;!--Description--&gt;Solid State Logic SSL12 SSL18 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2022 maybe usb compliant, bus powered, good pre-amps, up to 32-bit 192kHz AD/DA converters, 12-in 8-out, 
|-
| &lt;!--Description--&gt;Solid State Logic SSL2 SSL2+ MkII 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 maybe usb compliant, good pre amps ein -130 dBu, ad/dc, okay latency, 
|-
| &lt;!--Description--&gt;Solid State Logic 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant, 
|-
| &lt;!--Description--&gt; 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;  
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Topping E1x2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2023 maybe usb compliant, good 
|-
| &lt;!--Description--&gt;Topping Pro E2x2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2023 maybe usb compliant, good 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;UAD UA Apollo 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2012 maybe not usb compliant, 
|-
| &lt;!--Description--&gt;UA apollo 2nd Gen twin X (Duo/Quad), X4, X6, X8, X8P, and X16
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2015 bus compliant?, usb-
|-
| &lt;!--Description--&gt;UA apollo twin x quad 3rd Gen 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 bus compliant?, usb-
|-
| &lt;!--Description--&gt;Universal Audio Volt 1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2021 maybe usb compliant, good, 
|-
| &lt;!--Description--&gt;|Universal Audio Volt 276 2|76 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2021 maybe usb compliant, good, 
|-
| &lt;!--Description--&gt;Universal Audio Volt 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2022 maybe usb compliant, good, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Playback
| Records 
| Opinion 
|-
| &lt;!--Description--&gt;Akai EIE Pro AI01 Electromusic Interface Expander - 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 maybe not usb compliant, 4-in/4-out USB 2.0 audio interface with a built-in USB hub and MIDI I/O, up to 24-bit/96kHz 
|-
| &lt;!--Description--&gt;Akai EIE Pro AI02 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe not usb compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;|Alesis io2 io|2, io14 io|14, io26 io|26 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2006 bus powered but not usb compliant, okay pre-amps, 2, 4 or 8 mics respectively, 
|-
| &lt;!--Description--&gt;Alesis iO2 Express 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2010  not usb compliant, poor pre-amps, 
|-
| &lt;!--Description--&gt;Alesis Core 1 USB Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 maybe cc, mini usb, poor latency, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Apogee Duet 1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2009 firewire only, not usb compliant micro-usb with most features, , ,  two‑channel two‑in, two‑out, 
|-
| &lt;!--Description--&gt;Apogee Ensemble 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2009 firewire, not usb compliant micro-usb with most features, , ,  two‑channel 
|-
| &lt;!--Description--&gt;Apogee One USB 1st Gen 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 maybe not usb compliant micro-usb for basic features, , , single‑channel up to 48kHz
|-
| &lt;!--Description--&gt;Apogee One USB 2nd Gen 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe usb compliant usb- and maybe aa batteries, 
|-
| &lt;!--Description--&gt;Apogee Duet 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2022 maybe usb compliant usb-c with most features, , , 
|-
| &lt;!--Description--&gt;Apogee One USB 3rd Gen 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Apogee Ensemble Thunderbolt 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2020 maybe not usb compliant micro-usb with most features, , ,  two‑channel 
|-
| &lt;!--Description--&gt;Apogee Boom 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2022 maybe usb compliant usb-c, , , 
|-
| &lt;!--Description--&gt;Apogee Duet 3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2022 maybe usb compliant usb-c with most features, , , 
|-
| &lt;!--Description--&gt;Apogee 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;ART PRO Audio Usb Mix 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 maybe usb compliant bus powered, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Avid Digidesign Mbox 1 USB Audio 
| &lt;!--Vendor ID--&gt;0x0dba
| &lt;!--Product ID--&gt;01000
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2002 mbox original was usb1 and not a usb class compliant device, and had the much hated &quot;focusrite designed&quot; mic preamps, light blue front plate and the sticky out feet 
|-
| &lt;!--Description--&gt;Avid Digidesign Mbox 2 USB Audio 
| &lt;!--Vendor ID--&gt;0x0dba
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2005 midi not usb compliant 
|-
| &lt;!--Description--&gt;Avid Digidesign Mbox 2 Pro USB Audio 
| &lt;!--Vendor ID--&gt;0x0dba
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2006 not usb compliant 
|-
| &lt;!--Description--&gt;Avid Digidesign Mbox 2 Mini USB Audio 
| &lt;!--Vendor ID--&gt;0x0dba
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2007 not usb compliant 
|-
| &lt;!--Description--&gt;Avid Digidesign Mbox 2 Micro USB Audio 
| &lt;!--Vendor ID--&gt;0x0dba
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2009 not usb compliant 
|-
| &lt;!--Description--&gt;AVID MBox 3rd gen Mini or Standard but Pro is Firewire 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2010 maybe usb compliant, 
|-
| &lt;!--Description--&gt;behringer u-control uca202 
| &lt;!--Vendor ID--&gt;0x8bb
| &lt;!--Product ID--&gt;0x2902
| &lt;!--Revision--&gt;1.00
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 maybe usb compliant, draws a lot of power - dac ti burr-brown - no microphone pre-amp - 
|-
| &lt;!--Description--&gt;Behringer U-CONTROL UCA 222 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2009 maybe usb compliant,  - no microphone pre-amp - 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Black Lion Audio 2x2 evolution 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2021 maybe usb compliant but , okay with 109dB range - poor noise floor, 24-bit 192kHz Cirrus Logic CS4272, average latency, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Bomge 11s 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2021 
|-
| &lt;!--Description--&gt;Bomge 22s 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2021 
|-
| &lt;!--Description--&gt;Bomge BMG22 USB Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2021 usb-c, 24bit 192kHz but only use much lower, may have to spend time cleaning up some of the noise, high latency, 
|-
| &lt;!--Description--&gt;Bomge U202 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2022 usb-c, 32bit 192kHz but only use much lower, may have to spend time cleaning up some of the noise, high latency, 
|-
| &lt;!--Description--&gt;Bomge U204 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2022 usb-c, 32bit 192kHz but only use much lower , may have to spend time cleaning up some of the noise, high latency, 
|-
| &lt;!--Description--&gt;Bomge Mini 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2024 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;TI Burr-Brown PCM2702E PCM2704 PCM2704C Muse Audio Mini USB DAC board 
| &lt;!--Vendor ID--&gt;0x08bb 
| &lt;!--Product ID--&gt;0x2704
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant, no mic input - goodish quality
|-
| &lt;!--Description--&gt;TI Burr-Brown PCM2900 PCM2902 PCM2906 USB DAC board 
| &lt;!--Vendor ID--&gt;0x08bb
| &lt;!--Product ID--&gt;0x2900
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant, no mic input - goodish quality 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Depusheng MD22 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2022 usb-b powered, 24bit 192kHz though is 96kHz, 
|-
| &lt;!--Description--&gt;Depusheng USB Audio 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2023 usb-b powered, 24bit 192kHz though is 96kHz, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;|Emagic emi 2|6 em2|6 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2002 not uac 
|-
| &lt;!--Description--&gt;|Emagic emi 6|2m 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2005 not uac 
|-
| &lt;!--Description--&gt;|Emagic emi 6|2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2005 not uac 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Ego Systems, Inc. in Korea (ESI) joining with RIDI GmbH 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2006 maybe not usb compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;esi Mixvibes U46 Mk II USB audio 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2007 not usb compliant, usb-b powered, 
|-
| &lt;!--Description--&gt;ESI ESU22
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2008 maybe not usb compliant, 
|-
| &lt;!--Description--&gt;esi U24XL 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 maybe usb compliant, usb-b powered, 24 bits, 2 analogue inputs and outputs with 6.3 mm jack connection, Output L can be used as a headphone output, S / PDIF digital input - 
|-
| &lt;!--Description--&gt;esi U46XL 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 maybe usb compliant, usb-b powered, 
|-
| &lt;!--Description--&gt;ESI Originals, Inc ESIO MAYA22USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe usb compliant, usb-b powered, 1 xlr, 
|-
| &lt;!--Description--&gt;ESI MAYA44USB+ 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe usb compliant, usb-b powered,  xlr, 
|-
| &lt;!--Description--&gt;ESI Originals, Inc ESIO MARA22XTU 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 maybe usb compliant, usb-b powered, 1 xlr, 
|-
| &lt;!--Description--&gt;ESI U22XT
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 usb class compliant
|-
| &lt;!--Description--&gt;ESI Gigaport Ex
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2020 usb compliant?, usb-c usb3.1, , , 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;iConnectivity iConnectAUDIO2+ icaudio-02 USB audio interface
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;{{unk|2016 }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;LexiconPro - Omega 8x4x2 (USB-1.1)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2003 not usb complaint 
|-
| &lt;!--Description--&gt;Lexicon Alpha 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2006 not usb compliant, 
|-
| &lt;!--Description--&gt;Lexicon Lambda
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2006 may not be compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Line 6 Toneport UX1 and Tone Port UX2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2004  not usb compliant, 
|-
| &lt;!--Description--&gt;Line 6 TonePort UX8 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2005 maybe not class compliant, 
|-
| &lt;!--Description--&gt;Line 6 POD Studio UX1 UX2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2006  not usb compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Lokchonk UX22 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;[https://www.youtube.com/watch?v=ljSiNmudMm0 Lokchonk UX44HD] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2023 usb-b , , , 2in 2out only, average latency, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Mackie Onyx Artist 1·2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2006 maybe not usb compliant, usb-b powered, 
|-
| &lt;!--Description--&gt;Mackie Onyx Producer 2X2 USB Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 maybe usb compliant, usb-b midi 
|-
| &lt;!--Description--&gt;Mackie Onyx Blackjack
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 USB powered but maybe not usb compliant, Two Onyx Preamps, 2-in, 2-out which are combo Neutrik-type connectors to handle XLR, instrument or line level 
|-
| &lt;!--Description--&gt;Mackie 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 maybe usb compliant, , , 
|-
| &lt;!--Description--&gt;Media Assistance USB-One
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2009 not uac cc comliant, 
|-
| &lt;!--Description--&gt;M-Audio Fast Track USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2004 maybe not usb compliant, - guitar 
|-
| &lt;!--Description--&gt;M-Audio Fast Track Ultra (6 in 6 out) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2008 maybe usb cc providing 24-bit/96kHz audio capabilities but requires manual configuration of the mixer settings 
|-
| &lt;!--Description--&gt;M-Audio M-Track 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 usb compliant?, okay - guitar and vocal mainly 
|-
| &lt;!--Description--&gt;[https://htyp.org/M-Audio/Fast_Track_Ultra/Linux M-Audio FastTrack Ultra] and Ultra 8R 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2010 maybe usb compliant, low round-trip latency, okay octane pre amps, adc, 
|-
| &lt;!--Description--&gt;M-Audio M-Track 2x2M
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 usb compliant? usb-c - okay pre-amps, , 
|-
| &lt;!--Description--&gt;M-Audio M-Track (MkII) 2x2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2016 usb compliant? usb-c - okay pre amps, , 
|-
| &lt;!--Description--&gt;M-Audio M-Track Solo 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2021 usb compliant? - okay but issues, MJN4580C opamps (lower gain 55 dB at volume 9-10), ti PCM2900C ADC 16bit means there is a hard noise floor at -96 dB, plastic build no rf shielding, 
|-
| &lt;!--Description--&gt;M-Audio M-Track DUO 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2021 usb compliant? - okay but issues, MJN4580C opamps (lower gain 55 dB at volume 9-10), ti PCM2900C ADC 16bit means there is a hard noise floor at -96 dB, plastic build no rf sheild, 
|-
| &lt;!--Description--&gt;M-Audio Air
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant, okay 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;NI AK1 
| &lt;!--Vendor ID--&gt;0x17CC
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 maybe usb compliant, 
|-
| &lt;!--Description--&gt;[https://www.pogo.org.uk/~mark/linuxdj/ Native Instruments Traktor Audio 8 DJ], [ Traktor Audio 4 DJ], [ Traktor Audio 2 DJ], 
| &lt;!--Vendor ID--&gt;0x17cc
| &lt;!--Product ID--&gt;0x1978, 0x0839, 0x041C 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2009 not usb compliant uses snd-usb-caiaq module, [https://mixxx.discourse.group/t/problems-with-native-instruments-audio-8-dj-on-linux/14719/2 Audio 8 device has 4 subunits which are not recognized correctly], Cirrus Logic DACs spec'd at 24-bit/96KHz over a USB2, 
|-
| &lt;!--Description--&gt;NI Komplete Audio 6 Mk1 
| &lt;!--Vendor ID--&gt;0x17CC
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2011 maybe usb compliant, pre amps, 24bit 96kHz adc, ocassional dropouts, plastic build top with metal around 3/4, 
|-
| &lt;!--Description--&gt;Native Instruments NI Komplete Audio 1 and 2 USB 
| &lt;!--Vendor ID--&gt;0x17CC
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant, good pre amp ein -129.5 dBu, ad/dc, 
|-
| &lt;!--Description--&gt;[https://support.native-instruments.com/hc/en-us/articles/360014683497-Apple-Silicon-Compatibility-News Native Instruments Komplete Audio 6 Mk2] 
| &lt;!--Vendor ID--&gt;0x17CC
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant, pre amps, 24bit 192kHz adc, black aluminum glass build, 
|-
| &lt;!--Description--&gt;[ Native Instruments Traktor Pro] 
| &lt;!--Vendor ID--&gt;0x17cc
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2023 maybe usb compliant 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Novation AudioHub 2x4 NOVHUB01 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 maybe usb compliant, usb-b powered, no xlr, focusrite sounds inside, 
|-
| &lt;!--Description--&gt;Novation AudioHub 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Prodipe Studio 22 Pro
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe not usb compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Schiit HEL 1 USB Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019
|-
| &lt;!--Description--&gt;Schiit HEL 2 USB Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2021 gaming headsets mostly 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Roland Edirol UA-3 Audio Capture
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;1998 maybe not usb compliant, 
|-
| &lt;!--Description--&gt;Roland Edirol UA-30 Audio Capture
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;1999 not usb compliant, 
|-
| &lt;!--Description--&gt;Roland Edirol UA1A UA-1D Audio Capture
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2000 not usb compliant, 
|-
| &lt;!--Description--&gt;Roland Edirol UA-5 Audio Capture (Roland)
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2000 not usb compliant, 
|-
| &lt;!--Description--&gt;Roland Edirol UA-1000 Audio Capture
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2004 not usb compliant, 
|-
| &lt;!--Description--&gt;Roland Edirol UA-1EX, Cakewalk UA-1G  
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2005 not usb compliant driver also supports ASIO (Steinberg Audio Stream I/O Interface), noisy 
|-
| &lt;!--Description--&gt;Roland Duo Capture UA-11 
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2006 not usb compliant, 
|-
| &lt;!--Description--&gt;Roland QUAD-CAPTURE Analog 2x2 Digital 2x2 USB 2.0 4in/4out
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2005 not usb compliant, usb-b powered 
|-
| &lt;!--Description--&gt;[https://wiki.debian.org/DebianEdu/Documentation/Manuals/Rosegarden/Setup Roland Edirol UA-101 and UA-1000 (Clemens Ladisch driver)]
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2006 not usb compliant, 
|-
| &lt;!--Description--&gt;[https://github.com/mmueller-kaffeeschluerfercom/UA-25-Firmware-Modification Roland Edirol ua-25]
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2007 maybe usb compliant 16bit 44.1kHz sampling without MIDI but not USB class complient when in Advanced mode for 24bit or midi 
|-
| &lt;!--Description--&gt;Edirol by Roland USB AudioCapture UA-25EX 
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt;0x00e6, 0x00e7
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2008 maybe usb compliant if ADVANCED DRIVER switched to OFF might play and record at 44.1kHz and 16-bit samples 
|-
| &lt;!--Description--&gt;Roland Audio Interface V-Studio 20 VS-20 Cakewalk
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2010 maybe not usb compliant, usb-b powered, 1 xlr, 
|-
| &lt;!--Description--&gt;Roland Edirol UA55 UA-55 Quad Cakewalk 
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt;0x012f
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2011 not USB class compliant, 
|-
| &lt;!--Description--&gt;Roland DUO-CAPTURE EX UA-22 USB Audio
| &lt;!--Vendor ID--&gt;0x0582
| &lt;!--Product ID--&gt;0x0159
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe usb compliant but not be used with a USB 3.0 port that is not compatible with USB 2.0 specification, vs pre amps, adc, three AA batteries in base, or an AC adapter psb-1u 9V 2A - 
|-
| &lt;!--Description--&gt;Roland Rubix series Roland Rubix22 USB 2.0 Audio Interface
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2017 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Roland Rubix series Roland Rubix24 USB 2.0 Audio Interface
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2017 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Roland 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant 
|-
| &lt;!--Description--&gt;Steinberg MI2, Steinberg MI4
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2004 not usb compliant, 
|-
| &lt;!--Description--&gt;Steinberg (2004 Yamaha buys) MIDI interface hardware including the CC like CC121 CC-121 and CI1 CI2 series.
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2008 not usb compliant, 
|-
| &lt;!--Description--&gt;Steinberg UR12 UR22
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe not usb compliant, poor pre-amps, 
|-
| &lt;!--Description--&gt;Steinberg UR44 usb audio interface
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 maybe not usb compliant, poor pre-amps, 
|-
| &lt;!--Description--&gt;Steinberg UR242 audio interface
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2015 maybe usb compliant, usb powered or 5v psu, okay pre-amps, 
|-
| &lt;!--Description--&gt;Steinberg UR22mkII 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 maybe usb compliant, okay pre-amps ein -123 dBu, ad/dc, 
|-
| &lt;!--Description--&gt;Steinberg UR-RT 2 USB Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2018 maybe usb compliant, usb2.0 usb-b, pre-amps, ad/dc, 
|-
| &lt;!--Description--&gt;Steinberg UR44C (USB3) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2019 maybe usb compliant, 
|-
| &lt;!--Description--&gt;Steinberg URX22C UR22C  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2021 maybe usb compliant, preamps okay but little noisy, ad/dc. 
|-
| &lt;!--Description--&gt;Steinberg UR22 MkIII UR series
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 maybe usb compliant usb-c, okay pre-amps, adc, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Tapco LiNK.USB 2x2 (Loud technologies WA, USA) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2005 maybe not compliant, usb-b, poor pre-amps hum, latency issues, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;[https://git.alsa-project.org/?p=alsa-tools.git;a=blob;f=usx2yloader/README;hb=3843634ef0310a952b256bcb6a4ddd0ad4ebe396 Teac Tascam US-422 US-428 US2XYloader] 
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2000 not usb compliant, 
|-
| &lt;!--Description--&gt;Tascam US-122 US-224 
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2003 not usb compliant, needing firmware usx2yloader/us122fw.ihx for audio sound card - Tascam US-122 and US-122L are not the same - 
|-
| &lt;!--Description--&gt;Tascam US-122L 
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt;0x800e
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2006 not usb compliant, obsolete needs tascam_loader.ihx and us122fw.ihx firmware loaded each time unless automated 
|-
| &lt;!--Description--&gt;Tascam US122 US-122 Mk2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2004 not usb compliant although USB2 downgrade so using USB1.1 UHCI, tascam units suffer from high round-trip latency as do most typical USB units
|-
| &lt;!--Description--&gt;Tascam US144 US-144 Mk2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2004 maybe usb compliant although USB2 downgrade so using USB1.1 UHCI, tascam units suffer from high round-trip latency as do most typical USB units
|-
| &lt;!--Description--&gt;Teac TASCAM US-200 USB 2.0 Audio / MIDI Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2011 maybe not usb compliant, 
|-
| &lt;!--Description--&gt;Teac US-366 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2011 maybe not usb compliant, 
|-
| &lt;!--Description--&gt;Teac TASCAM US-600 USB 2.0 Audio / MIDI Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2011 maybe not usb compliant, 
|-
| &lt;!--Description--&gt;Teac TASCAM US-800 USB 2.0 Audio / MIDI Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no|no driver}}
| &lt;!--Records--&gt;{{no|no driver}}
| &lt;!--Opinion--&gt;2011 may not be totally usb compliant 
|-
| &lt;!--Description--&gt;Teac Tascam iU2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{no| }}
| &lt;!--Records--&gt;{{no| }}
| &lt;!--Opinion--&gt;2012 maybe not usb compliant, 
|-
| &lt;!--Description--&gt;Teac Corp Tascam US-2x2
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2014 usb compliant?, 5v dc power, midi out in, 
|-
| &lt;!--Description--&gt;Teac Corp Tascam US-4x4
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; usb compliant?, 
|-
| &lt;!--Description--&gt;Teac Tascam US-16x08 US-20x20
| &lt;!--Vendor ID--&gt;0x0644
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;teyun q12 Q-12, q22 Q-22 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant - unknown pre amp, unknown ad/dc, 
|-
| &lt;!--Description--&gt;Teyun q26 Q-26, q24 Q-24 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe usb compliant - unknown pre amp, unknown ad/dc, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Yamaha UW500
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2000 not class compliant, 
|-
| &lt;!--Description--&gt;Yamaha Audiogram 3 USB Digital Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2012 maybe usb compliant, okay pre amp, 16bit 44kHz adc no advanced features without dedicated asio driver, 1 xlr, 1 instrument, 
|-
| &lt;!--Description--&gt;Yamaha Audiogram 6 USB Digital Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2013 maybe usb compliant, okay, 2 xlr, 2 instrument, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Zoom UAC-232 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe not usb compliant, okay, 
|-
| &lt;!--Description--&gt;Zoom UAC
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; maybe not usb compliant, okay, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Playback
| Records 
| Opinion 
|-
| &lt;!--Description--&gt;[http://www.arcam.co.uk/products,rseries,usb-dacs,rPAC.htm Arcam rPac] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Audioquest Dragonfly 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Audioengine D1 Premium 24-bit DAC 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Beresford TC-7520 (Burr Brown PCM 1716) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Beresford TC-7520 + Burson Buffer + MK3 JKSPDIF
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;[http://epiphany-acoustics.co.uk/products-page/dacs/e-dac-24bit-miniature-usb-dac/ Epiphany E-DAC 24bit] ES9023 DAC chip 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Firestone Audio FUBAR II Mk2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Firestone Audio iLoveTW 24Bit USB DAC
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;FiiO D5 ta2020 chip amp 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;FiiO E07K Andes 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;FiiO E17 Alpen 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;GoVibe Magnum 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;GoVibe Martini-U 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;GoVibe Vulcan 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Halide Design DAC HD (Wolfson WM8716) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;HRT Steamer II USB DAC 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;John Kenny JKDAC uses a 24-bit/192&amp;nbsp;kHz Sabre ES9022 DAC or better JKDAC32 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt; iBasso D12  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Leckerton UHA-6S MKII  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;MyST 1866 PortaDAC 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Objective DAC ODAC+O2  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Rega DAC (Wolfson WM8742) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Playback
| Records 
| Opinion 
|-
| &lt;!--Description--&gt;[http://www.henryaudio.com/open-source.php Henry Audio USB DAC 128 also known as QNKTC AB-1.2 open source DAC] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Henry Audio mkII 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;AKM4430 DAC chip comes from Asahi Kasai 
|-
| &lt;!--Description--&gt;DevilSound USB DAC 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Zoom U series
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;KingRex UD-01 SE (Burr-Brown PCM 2702E) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;SuperPro 24/192 USB DAC (24bit 192&amp;nbsp;kHz, CS-4398 D/A chip) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Playback
| Records 
| Opinion 
|-
| CMedia CM108 7.1ch emulation I2S in and out
| 0x1926
| 0x0003
| 0x0100
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| [http://www.lindy.co.uk/usb-2-audio-adapter/42961.html Lindy USB 2.0] (Chipset CM108)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| Speed-Link SL-8850-SBK Vigo ([http://mightyohm.com/forum/viewtopic.php?p=1036#p1030 CMedia CM108])
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| Dynamode USB SOUNDCARD 2.0 
| &lt;!--Vendor ID--&gt;0x0003
| &lt;!--Product ID--&gt;0x1130
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| Dynamode Virtual 7.1 USB-SOUND7 (C-Media )
| 0x0d8c
| 0x000c 0x000e
| 1.00
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Generic White box with very little red led and white USB lead (CMedia )
| &lt;!--Vendor ID--&gt;0x0d8c
| &lt;!--Product ID--&gt; 0c000e
| &lt;!--Revision--&gt;1.00
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Playback
| Records 
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| CM109 CiT SC-U119 5.1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Playback
| Records 
| Opinion 
|-
| CMedia CM1197.1ch I2C MCU port Penguin 
| 0x0D8C
| 0x0000
| 0x010
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Playback
| Records 
| Opinion 
|-
| &lt;!--Description--&gt;Sweex 7.1 Startech External USB, WMA Blue metal box SYBA SD-AUD20040, Sabrent USB-SND8, Sewell Vantec NBA-200U (C-Media CM6206 CM106 like) 
| &lt;!--Vendor ID--&gt;0x0d8c
| &lt;!--Product ID--&gt;0x0102
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;50/50 if the item is detected but does not work 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Creative Labs SoundBlaster X-fi 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Creative X-Fi Go 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Creative X-Fi 5.1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Creative Sound Blaster Play! USB sound adapter (SB1140) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; working with [http://www.amiga.org/forums/showpost.php?p=646431&amp;postcount=15 Deneb on OS3] 
|-
| &lt;!--Description--&gt;Asus Xonar U1 (ASUS UA100 USB Audio Chip) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Asus Xonar U3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Playback
| Records 
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Griffin iMic 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;M-Audio Transit
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Icemat Siberia (steel series) (Cmedia chipset) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;JMTek HY554, ZyXEL NSA-220, Logilink (Tenx Technology TP6911 and SSS-1623 headphone set) 
| 0x0C76 0x1130
| 0x1605 0x1607  0xf211
| 0x
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt; reports on other OS not good 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Plantronics &quot;DSP Adapter-01&quot; (or &quot;USB Adapter-02&quot;) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Rocksmith Real Tone Cable 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;RSA Intruder Predator 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;StarTech ICUSBAUDIO7
| &lt;!--Vendor ID--&gt;0x0d8c
| &lt;!--Product ID--&gt;0x000c
| &lt;!--Revision--&gt;1.00
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Stoner Acoustics UD100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Teac UDH01-B  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Terratec Aureon 5.1 USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Terratec Aureon 5.1 USB MKII
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;TerraTec Electronic GmbH Aureon Dual USB
| 0x0ccd
| 0x0077 
| &lt;!--Product ID--&gt; 
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Terratec Phase26
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Trust 510 EX 5.1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Logitech A-5572A USB 2.0  to 3.5mm jacks Virtual 7.1 Surround Sound Adapter or accessory of Logitech Clearchat pro USB or Logitech USB Headset H530 
| &lt;!--Vendor ID--&gt;0x0003 
| &lt;!--Product ID--&gt;0x046D
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Trumix TM-10 USB Audio Interface 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;2024  maybe cc 
|-
| &lt;!--Description--&gt;Trumix TM-12 USB-C 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;2024 maybe cc usb compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Turtle Beach Audio Advantage Amigo Micro II USB Sound Card &amp; Headset Adapter 
| &lt;!--Vendor ID--&gt;0x10F5
| &lt;!--Product ID--&gt;0x0211
| &lt;!--Revision--&gt;0100
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;Vantec NBA-100U 7.1 Channel 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt;{{unk| }}
| &lt;!--Records--&gt;{{unk| }}
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Playback--&gt; 
| &lt;!--Records--&gt;
| &lt;!--Opinion--&gt;
|}

 Companies including Access, Alesis, Allen&amp;Heath, American Audio, CME, ESI, Infrasonic, Lexicon, Numark, Presonus, Reloop, SIMS, Sound Devices, Steinberg, Swissonic, Tascam, Terrasoniq, Terratec, Yamaha and Yellowtec decided to license and bundle this driver. So fully functional custom drivers are available for Access Virus TI, Access Virus TI snow, Alesis Multimix 8 USB2.0, Alesis Multimix 16 USB2.0, Allen&amp;Heath XONE:2D, Allen&amp;Heath XONE:3D, Allen&amp;Heath XONE:4D, Allen&amp;Heath XONE:DX, Allen&amp;Heath XONE:DB4, American Audio Versa Port, CME XCORPIO, ESI ESU1808, ESI Gigaport AG / DG, ESI Maya 44 USB, Infrasonic Amon, Lexicon I-ONIX U22, Lexicon I-ONIX U42S, Lexicon I-ONIX U82S, Mindprint DI-MOD USB, Numark DJ IO, Numark NS6, Numark NS7, Numark Omni Control, Numark V7, Presonus Audiobox USB, Reloop Digital Jockey, SIMS Primus, Sound Devices USB pre, Steinberg MI2, Steinberg MI4, Swissonic Easy USB, Tascam M-164UF, Tascam US-122L, Tascam US-144, Tascam US-Tascam US-144mkII 122mkII, Tascam US-200, Tascam US-600, Tascam US-1641, Tascam US-1800, Tascam US-2000, Terratec Area 61, Terrasoniq Phase X64, Terratec Phase 26 USB, Yamaha UW10, Yamaha UW500, Yellowtec PUC2 and many others.

Well, those companies are using the same driver framework because all of those interfaces use the same microprocessor/firmware architecture to communicate with the USB bus. Just like almost all FireWire audio interfaces use the same TC Dice or BridgeCo chipsets. Usually it does not make sense for companies to develop their own USB1.1/USB2/FW framework for a product they are going to sell for &lt;$500.

However, that isn't the end of the story. The companies who develop audio interfaces implement different features into their devices and must update the driver and firmware to accommodate those features. That is where things can go wrong. Sometimes there is miss-communication about how things are coded, sometimes the developer who started a project leaves without transferring his knowledge to his successor, etc. You have to keep in mind that there are no &quot;big&quot; computer audio companies. Even the companies that seem big in the scale of the market, probably have fewer employees than you'd think.

A very well made interface that is designed from scratch from the ground up would be a very expensive device, regardless of whether it's USB, FW, PCIe or whatever.

Round-trip latency is the sum of the following:
&lt;pre&gt;
    ASIO input buffer
    ASIO output buffer
    A/D D/A converter latency
    The driver's hidden safety buffer
&lt;/pre&gt;
At a 64-sample ASIO buffer size/44.1k, Tascam units yield ~18ms total round-trip latency.

Typical USB audio interfaces use a large hidden safety buffer.
This helps ensure glitch-free playback... even under less than ideal circumstances. But... this comes at the expense of much higher round-trip latency. Short of doubling the sample-rate, there's no means of mitigating the higher round-trip latency.
If you have no plans of ever monitoring in realtime thru software based EFX/processing (ie: playing/monitoring DI bass thru an AmpSim plugin as you're playing), then this may not matter to you.
If you want the ability this play/monitor in realtime thru software based EFX/processing, make sure to get an audio interface that yields low round-trip latency.

As a point of reference the best PCI/e audio interfaces yield about 5ms total round-trip latency at a 64-sample ASIO buffer size/44.1k
The best Firewire and USB units yield 5.5-5.6ms total round-trip latency at those same settings.
Typical USB and Firewire units (that use a large hidden safety buffer) yield 12-18ms total round-trip latency at those same settings.

Anything above ~6ms starts to feel sluggish.
Anything above ~10ms feels like playing thru molasses.


USB Microphones 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;C-Media Electronics, Inc. CM108 Audio Controller Mic
| &lt;!--Vendor ID--&gt;0x0d8c
| &lt;!--Product ID--&gt;0x013c 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Elgato WaveMic 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Elgato Wave:1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 no driver }}
|-
| &lt;!--Description--&gt;Elgato Wave:3
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 no driver lightweight }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;hyperx solocast 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 no driver}}
|-
| &lt;!--Description--&gt;hyperx quadcast 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Sennheiser CC510 USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;Alesis USB-Mic microphone podcasting kit 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Audio-Technica AT2020 (AT202) AT4040
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Audio-Technica AT2035 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Behringer B1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Blue Microphones Snowball 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Blue Microphones Snowball iCE
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| cardioid only }}
|-
| &lt;!--Description--&gt;Blue Microphones Yeti 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|can pick up a lot of background noise but not sure if right mode used }}
|-
| &lt;!--Description--&gt;Blue Microphones Yeti Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| can pick up a lot of background noise but not sure if right mode used }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;MXL 2001A/600 Studio Microphone Pack / MXL 2003A Studio Condenser
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Microsoft LifeChat LX-3000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Namtai SingStar(TM) PS2 SCEH-0001 USBMIC 
| &lt;!--Vendor ID--&gt;0x1415
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;0.01
| &lt;!--Opinion--&gt;{{unk| mono microphones }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Neumann MT48 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Razer Seiren X 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Razer Seiren Mini USB Condenser Microphone 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Rockband USB Mic 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Rode NT1A VideoMic Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Rode Podcaster 2 USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| RODECaster Pro usb audio compatible}}
|-
| &lt;!--Description--&gt;Rode NT1A NT2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|  NT2 better }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Roland R-07
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Samson Go Mic - Portable USB Microphone for Recording 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| mini usb r.h.s. and clip on the bottom left hand side}}
|-
| &lt;!--Description--&gt;Samson Go Mic Clip On USB Microphone 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| switch to choose between Cardiod, Omni and -10&amp;nbsp;dB modes, a 3.5mm headphone socket and a USB socket}}
|-
| &lt;!--Description--&gt;Samson C01U  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| cardoid only}}
|-
| &lt;!--Description--&gt;Samson C03U 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Shure MV7 USB Podcast Microphone 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;SONY PCM-D50 handy 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| one mini usb 5V, }}
|-
| &lt;!--Description--&gt;Sony PCM-M10 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| one mini usb out 5V, }}
|-
| &lt;!--Description--&gt;SONY 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| one mini usb out, }}
|-
| &lt;!--Description--&gt;SONY 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| one mini usb out, }}
|-
| &lt;!--Description--&gt;TASCAM DR-1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008, one mini usb out, lithium battery}}
|-
| &lt;!--Description--&gt;Tascam DR-07 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009, one mini usb out, aa battery}}
|-
| &lt;!--Description--&gt;Tascam DR05 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011, one mini usb port for file transfer and charging the AA batteries }}
|-
| &lt;!--Description--&gt;Tascam DR-40
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011  mini usb aa battery }}
|-
| &lt;!--Description--&gt;Tascam DR-07mkII
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012 , one mini usb out, }}
|-
| &lt;!--Description--&gt;Tascam DR-05X 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 , one micro usb out, }}
|-
| &lt;!--Description--&gt;Tascam DR-07X 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 , one micro usb out, }}
|-
| &lt;!--Description--&gt;Tascam DR-40X
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 , one micro usb 3 aa battery }}
|-
| &lt;!--Description--&gt;Tascam DR-05XP 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 , one usb-c , }}
|-
| &lt;!--Description--&gt;Tascam DR-07XP 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 , one usb-c , }}
|-
| &lt;!--Description--&gt;Tascam DR-40XP
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 , one usb-c, }}
|-
| &lt;!--Description--&gt;Tascam DR-100mkIII 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| , usb , }}
|-
| &lt;!--Description--&gt;Tascam 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| , usb , }}
|-
| &lt;!--Description--&gt;Zoom H4 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2006 no driver, mini usb 5V }}
|-
| &lt;!--Description--&gt;Zoom H2 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt;0x0095
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2007 no driver, mini usb 5V audio i/f USB Card and USB Audio; press the Record button when USB Audio is displayed. Press Record again to choose the default }}
|-
| &lt;!--Description--&gt;Zoom H4n 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2009 no driver, mini usb 5V }}
|-
| &lt;!--Description--&gt;Zoom H1 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt;0x0120
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2010 no driver, mini usb 5V and display will alternate between USB Card and USB Audio; press the Record button when USB Audio is displayed. Press Record again to choose the default }}
|-
| &lt;!--Description--&gt;Zoom H2n 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011 no driver, mini usb 5V audio i/f press the Record. Press Record again to choose the default }}
|-
| &lt;!--Description--&gt;Zoom H4n PRO 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2011 no driver, mini usb 5V }}
|-
| &lt;!--Description--&gt;Zoom H6 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2013 untested, 2xlr, 5v mini usb, }}
|-
| &lt;!--Description--&gt;Zoom H5 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014 no driver, 5v mini usb, 2 xlr, }}
|-
| &lt;!--Description--&gt;Zoom H1n-vp handy 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 no driver, mini usb 5V }}
|-
| &lt;!--Description--&gt;Zoom H6studio 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 untested}}
|-
| &lt;!--Description--&gt;Zoom 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|no driver}}
|-
| &lt;!--Description--&gt;Zoom Q3
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2008 untested usb a cord, no hdmi, 480p}}
|-
| &lt;!--Description--&gt;Zoom Q3HD Handy Video Recorder 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2010 untested, built in usb-a cord, mini hdmi, 1 hour on 2 AA batteries, H.264 movies 480p }}
|-
| &lt;!--Description--&gt;Zoom Q2HD Handy 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2012 untested, up 720p but no stablisation, mini usb cord, 1 hour on 2 AA batteries}}
|-
| &lt;!--Description--&gt;Zoom Q4
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014 untested, li-ion battery}}
|-
| &lt;!--Description--&gt;Zoom Q4N 
| &lt;!--Vendor ID--&gt;0x1686
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2015 untested, li-ion battery}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Audio Technica ATR4697-USB Boundary Microphone
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;CAD Audio CAD USB Condenser Boundary Microphone 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;MXL AC-44 Boundary Conferencing Mic 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Samson Audio SAUB1 Boundary Microphone (USB)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|}


USB Speakers 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Focal XS 2.1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


USB Headset Wired/Wireless 
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Logitech Vantage Wired (came free with PS2 Socom3)
| 
| 
| 
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Logitech G330 
| 
| 
| 
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Logitech Premium USB Stereo Headset 350
| 
| 
| 
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Plantronics DSP-300 
| 
| 
| 
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Plantronics GameCom 777
| 
| 
| 
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;Wireless
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Logitech G-930 Wireless
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| [http://www.makeuseof.com/tag/set-usb-wireless-earphones/ Plantronics Audio 995 Wireless RF] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| Sennheiser  Wireless
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


[https://www.youtube.com/watch?v=Be1e0QPIPK0 Mixers]

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;ALESIS MULTIMIX 4 CHANNEL USB MIXER
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Alesis - MultiMix 8 USB FX (USB 1.0)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2010 usb compliant?, up to 16-bit/48kHz, 18v 500mA - 
|-
| &lt;!--Description--&gt;Alesis - MultiMix 8 USB 2.0 FX (USB 2.0)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2012 usb compliant?, up to 16-bit/48kHz, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Allen&amp;Heath MixWiz16
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; maybe not usb compliant, 
|-
| &lt;!--Description--&gt;Allen and Heath ZED Power 1000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb 8 xlr, usb-b out, }}
|-
| &lt;!--Description--&gt;Allen &amp; Heath ZEDi-10
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; maybe not usb compliant, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Behringer XENYX 302USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 5-Input Mixer/Audio Interface - 1 xlr - }}
|-
| &lt;!--Description--&gt;Behringer Xenyx Q502USB Mixer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|no driver}} Behringer 2*18.5V 250ma psu - 1 xlr - phanton power - 
|-
| &lt;!--Description--&gt;Behringer Xenyx Q802USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} Behringer 2*18.5V 250ma psu - 2 xlr - phanton power - 
|-
| &lt;!--Description--&gt;BEHRINGER XENYX 1204USB 8-Channel 2-Bus Mixer USB/Audio Interface Studio/Live
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} iec kettle psu lead - can develop constant background hiss over time 
|-
| &lt;!--Description--&gt;Behringer XENYX X1222USB
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver - 12-Channel Analog Mixer with USB Interface and Effects}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;Depusheng HT-7 HT7USB 7 Channel Audio Mixer
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2023 cheap no driver, USB MP3 player to work, format your USB stick Fat32 as a Logical drive - not primary}}
|-
| &lt;!--Description--&gt;Depusheng XT7 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2025 cheap no driver}}
|-
| &lt;!--Description--&gt;Depusheng DT8 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2025 cheap no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;Spirit soundcraft Folio FX8 with Lexicon Effects Processor
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} unusual power connector - [https://github.com/lack/soundcraft-utils usb routing] -  
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;Weymic Professional F7 7-Channel 2-Bus Mixer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2022 no driver, cheap mixer with 3pin ac input (introduces noise) and 1 usb-a port}}
|-
| &lt;!--Description--&gt;Weymic Professional F7-Pro 7-Channel 2-Bus Mixer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2022 no driver}}
|-
| &lt;!--Description--&gt;Weymic A80 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2024 no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;Yamaha 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
|}


Mixer no hardware usb 

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;ALTO Lynx MIX82FX Audio Mixer
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;Alto L16 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;Behringer MXUL5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;Behringer MX602A 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;Behringer Eurorack UB502
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb 17.5V 3pin psu needed}}
|-
| &lt;!--Description--&gt;Behringer Eurorack UB802 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb 2 xlr,}}
|-
| &lt;!--Description--&gt;Behringer Eurorack UB1002 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb 2 xlr,}}
|-
| &lt;!--Description--&gt;Behringer Eurorack UB1202 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb 4 xlr, }}
|-
| &lt;!--Description--&gt;Behringer Eurorack UB1602 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;Behringer RX1602 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;Behringer 802 XENYX 8-Input 2-Bus Mixer Small Format Mixer
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} Behringer 18.5V ???ma psu - 2 xlr - phanton power - 
|-
| &lt;!--Description--&gt;Behringer Xenyx 502 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;Behringer Xenyx 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;Behringer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;IMG stage Line MMX-122 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb, 4 xlr, iec cable}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection}}
|-
| &lt;!--Description--&gt;Mackie 802VLZ4 Mackie 802-VLZ4
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb , psu}}
|-
| &lt;!--Description--&gt;Mackie 1202-VLZ Pro
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb, mains iec}}
|-
| &lt;!--Description--&gt;Mackie Mix5 Mixer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}} 18v 300mA psu - 5 Channel - 
|-
| &lt;!--Description--&gt;Mackie Mix8 Mixer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}} 9v x2 600mA psu - 
|-
| &lt;!--Description--&gt;Mackie MIX12FX
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb, 4 xlr, 9v 500mA x2 psu, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no usb}}
|-
| &lt;!--Description--&gt;[https://www.soundcraft.com/en/product_documents/en/owners_manual Soundcraft] Spirit Folio F1 Fader 100 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} 16 Channel Mixer - 
|-
| &lt;!--Description--&gt;Soundcraft EPM6 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection}}
|-
| &lt;!--Description--&gt;Soundcraft EPM8 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection}}
|-
| &lt;!--Description--&gt;Harman Soundcraft EPM 12 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}} iec kettle power lead - 
|-
| &lt;!--Description--&gt;Soundcraft EPM 16
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;Soundcraft Notepad 8FX
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection}}
|-
| &lt;!--Description--&gt;Soundcraft Notepad UI12
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; connect via wifi 
|-
| &lt;!--Description--&gt;Soundcraft Notepad UI16
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt; connect via wifi 
|-
| &lt;!--Description--&gt;Soundcraft Notepad 124FX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection, 14.8V x2 3 pin psu}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection}}
|-
| &lt;!--Description--&gt;t.mix xmix 1402fx mp usb
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection, mains iec, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no hardware usb connection}}
|-
|}


==Webcameras==

A USB camera has two dedicated chips: a controller or bridge and an image sensor.

There was no Commodore support for video interfaces. The only commercial, now discontinued application that defined some sort of standard was VHI Studio by iospirit.

===OLD standards===

See [http://www.e3b.de/usb/main_supported_e.html support pages] and [http://www.e3b.de/usb/main_faq_e.html here] and some [http://webcam-osx.sourceforge.net/cameras/index.php?orderBy=status further compatibility]


Pencam STV680
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| AIPTEK stv680 
| 0x0553 
| 0x0202 
| 
| {{N/A|untested}}
|-
| Konica e-mini 
| 0x04c8 
| 0x0722 
|
| {{N/A|untested }}
|-
| DigitalDream l'espion XS 
| 0x1183 
| 0x0001 
|
| {{N/A|untested}}
|-
| [http://reviews.cnet.com/webcams/creative-webcam-go/1707-6502_7-1446174.html Creative WebCam Go mini] 
| 0x041e 
| 0x4007 
|
| {{N/A|untested}}
|-
|}


SonixcamTool (Sonix webcams and derivates)

'''Note [http://amigadev.free.fr/sonix/ some] Sonix Webcams with a Sonix SN9C1xx controller ''and'' a pas106b or tas5110c1b sensor support bulk mode which works even with pciusb.device!'''
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Macally IceCam II
| 0x0c45
| 0x05d8
| 
| {{N/A|untested}}
|-
| Sweex MiniCam 100K 
| 0x0c45 
| 0x6005 
| 
| {{N/A|untested - sensor tas5110c1b}}
|-
| Macally IceCam Portable 
| 0x0c45
| 0x6007
| 
| {{N/A|untested - sensor tas5110d}}
|-
| Sweex 100K 
| 0x0c45 
| 0x6009 
| 0x0101
| {{yes|bulk works - sensor pas106b}}
|-
| [http://www.epinions.com/pr-Chicony_TwinkleCam_Webcam/display_~full_specs Chicony Twinkle DC-2110A] 
| 0x0c45
| 0x600d
| 
| {{no|no}}
|-
| Unknown
| 0x0c45
| 0x601e
| 
| {{no|no}}
|-
| USB PC Camera (SN9C102)
| 0x0c45 
| 0x6028
| 
| {{no|no - sn9c10x + pas202b}}
|-
| Trust SpaceC@m 120 and 150
| 0x0c45 
| 0x6029
| 
| {{N/A|untested - sensor pas106a}}
|-
| HiRes Webcam Live
| 0x0c45 
| 0x602c
| 
| {{no|no - sensor ov7630}}
|-
| [http://www.sweex.com/en/assortiment/sound-vision/webcams/JA000020 Sweex USB Webcam 300K]
| 0x0c45
| 0x608f
| 
| {{no|no - sensor ov7630}}
|-
| Speedlink Sphere Webcam SL-6820, 350K
| 0x0c45
| 0x613c
| 0x0101
| {{N/A|untested - sensor HV7131R}}
|-
| WB-3250P
| 0x0c45
| 0x613e
| 
| {{no|no - sensor ov7630}}
|-
| Unknown
| 0x0c45 
| 0x6207
| 
| {{no|no}}
|}

&lt;pre&gt;
micromaxx USB Camera 	STM 	1363 	514 	works 	---
USB Tower 	Lego 	1684 	1 	works 	need NCQ
Trust Spycam 100plus 	STM 	1363 	514 	works
&lt;/pre&gt;


ov51x.class - no driver
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| D-Link VGA Webcam (640x480) 
| 0x05a9
| 0x8519
| 
| {{no|no driver}}
|-
| Sony PS2 EyeToy Logitech/Logicool Black (ov519) SCEH-0004 
| 0x054c
| 0x0154
| 
| {{no|no driver}}
|-
| Sony PS2 EyeToy Namtai Silver (ov519) SLEH-00031 SLEH-00030
| 0x054c
| 0x0155
| 
| {{no|no driver}}
|-
|}


===UVC.class - [https://www.usb.org/document-library/video-class-v15-document-set USB Device Class Definition for Video Devices or USB Video Class]===

 AROS needs realtime isochronous transfers in EHCI and XHCI, then a usb uvc.class which might create a virtual UVC.VHI type device driver for use by AROS apps 

since 2019 the market is filled with UVC Compliant USB HDMI Capture

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;Acasis 4K30 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|}}
|-
| &lt;!--Description--&gt;Acasis 4K60 HD VS009
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|4k 60hz ok for chat streams}}
|-
| &lt;!--Description--&gt;Acasis 4K60 HDMI HDR Game Live Video Capture
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| for chat streams }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;AJA U-tap HDMI 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|}}
|-
| &lt;!--Description--&gt;ASUS TUF CU4K30 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;ATEN CAMLIVE HDMI to USB-C UVC Video Capture adapter UC3020 HDMI (F) TO USB-C M 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 possibly UVC and UAC standard support allows up to 1080P @ 60}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Avermedia Live Streamer Cap 4K - BU113 
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 uvc usb3}}  
|-
| &lt;!--Description--&gt;AVerMedia GC515 video capturing device 
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 USB 3.2 Gen 1 (3.1 Gen 1)}}
|-
| &lt;!--Description--&gt;AVerMedia Live Gamer Ultra GC553
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 usb3 powered by Type C USB cable and 4K HDMI cable}}
|-
| &lt;!--Description--&gt;AVerMedia Live Gamer Ultra S GC553PROW 302AGC553DL2 
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt;0x1553
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 powered by good quality type C USB3 cable and 4K HDMI 2.0 cable}}
|-
| &lt;!--Description--&gt;AVermedia Live Gamer Mini GC311 302AGC311DG9 
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt;0x1311
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 uvc compliant up to 1080p 60fps capture and supports internal hardware H.264 encoding - if flashing blue light try another '''quality''' micro usb cable - }}
|-
| &lt;!--Description--&gt;AVerMedia Ez Recorder 330 (ER330) 
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 designed to work independently and is generally not compatible as a plug-and-play UVC capture card }}
|-
| &lt;!--Description--&gt;AVerMedia Live Gamer extreme3 GC551G2 (LGX3) 
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt;0x3551
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 uvc compliant for intensive gaming streams, some vrr but no hdr with maximum recording resolution of 4K30/1080p60 from fully wired usb3 compatible cable - passing through 4K60/1080p120 Game Capture video capturing device HDMI}}
|-
| &lt;!--Description--&gt;AVerMedia Live Gamer Ultra Pro GC553Pro 
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 usb3 }}
|-
| &lt;!--Description--&gt;AVerMedia Live Gamer Ultra 2.1 GC553G2 61GC553G20BV video capturing device 
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 USB 3.2 Gen 1 (3.1 Gen 1)}}
|-
| &lt;!--Description--&gt;AVerMedia GC575
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 usb3 powered by Type C USB cable and 4K HDMI cable}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;AVMatrix 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;ClonerAlliance Flint 4KP Plus 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;DIGITNOW U600 video capture card 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 uvc uac  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Epiphan AV.io HD
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Epiphan AV.io 4K 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Elgato Cam Link 4K 
| &lt;!--Vendor ID--&gt;0x0FD9
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 uvc }}
|-
| &lt;!--Description--&gt;[https://github.com/elgatosf/capture-device-support Elgato HD60 S+]
| &lt;!--Vendor ID--&gt;0x0FD9
| &lt;!--Product ID--&gt;0x006C, 0x006E
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 4K 30FPS capture, 1080p 60FPS uvc}} 
|-
| &lt;!--Description--&gt;Elgato HD60 X 
| &lt;!--Vendor ID--&gt;0x0FD9
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 uvc }}
|-
| &lt;!--Description--&gt;Elgato Cam Link 4K HDMI video capture card 
| &lt;!--Vendor ID--&gt;0x0FD9
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 uvc compliant but can have usb disconnects}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;EVGA XR1 USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 USB 3.0 device with 1080/60 capture and 4K/60 passthrough}}
|-
| &lt;!--Description--&gt;EVGA XR1 lite USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 USB 3.0 device }}
|-
| &lt;!--Description--&gt;EVGA XR1 Pro USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 USB 3.0 device with 1080/60 capture and 4K/60 passthrough}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;EZcap Game Link Raw - ezcap321 usb3.1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 2160p30, 1080p120 and 1440p60 HDMI input and pass-through. - 1080p120, 2160p30 and 1440p60 recording. - Latency less than 50ms uvc}} 
|-
| &lt;!--Description--&gt;EZCap GameDock Ultra 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 record at 4K30, 1440p60, and 1080p120}}
|-
| &lt;!--Description--&gt;EZcap 360 Game Capture Extreme 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2023 USB 3.0, 4K 60FPS passthru and 1080p 240FPS}}
|-
| &lt;!--Description--&gt;EZCAP 364 GameDock Extreme 2.1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 }} 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Genki ShadowCast 1 &amp; 2, the Pro version 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;HAUPPAUGE HD PVR Pro 60 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021  4K in/Out 1080P 60fps Capture and Streaming PC Connected and Stand Alone }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;INOGENI 2830 HDMI 4K to USB 3.0 UHD 1080p Video Capture Card 4K2USB3
| &lt;!--Vendor ID--&gt;0x2997
| &lt;!--Product ID--&gt;0x0004
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 uvc compliant made in Canada - usb3-b socket and 1 hdmi 1080p from 23.98 up to 60p, 4K@30 fps maybe - }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Kondor Blue 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Nanjing Magewell Electronics Co ltd USB 3.0 XI100DUSB-HDMI Pro Capture 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2013 }}
|-
| &lt;!--Description--&gt;Magewell USB3.0 Silver HDMI Full HD Video Capture Device 1080p 32011 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2013 usb audio extract HDMI embedded audio output via headphones}}
|-
| &lt;!--Description--&gt;Magewell USB capture HDMI PLUS 2K 32040 320400000
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2014 captures video up to 1920×1200, 1920×1080 or 2048×1080 at 60 fps over an HDMI capture from devices such as game consoles in up to DCI 4Kp60 4:2:0 input resolution, and it automatically upscales/downscales the signal to 2K for recording or streaming}} 
|-
| &lt;!--Description--&gt;Magewell USB capture HDMI Gen2 32060 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2015 1080p gets hot, 165M HDMI receiver, max input 2048x1080 60fps 4:4:4, RGB/YUV 4:4:4 8/10/12-bit, YUY 4:2:2 12-bit, up to 8-channel 24-bit HDMI-embedded audio at 192kHz, HDMI 1.4a, output from 480p to 1080p, YUY2/UYVY/RGB24/RGB32 support video cropping, up/down scaling, de-interlacing, aspect ratio conversion, color format conversion, frame rate conversion, flip and mirror, up to 2-channel IEC60958 audio streams, 5V 0.5A 2.5W, }}
|-
| &lt;!--Description--&gt;Magewell USB Capture 4K Plus 32090 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 limited by the bandwidth of USB 3.0, the maximum frame rate can only reach 30 fps when capturing}}
|-
| &lt;!--Description--&gt;Magewell USB Capture 4K PRO
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 }}
|-
| &lt;!--Description--&gt;Magewell Pro Convert IP to USB 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|Captures one network eth NDI® High Bandwidth, NDI® HX2, NDI® HX3 sources or H.264/H.265 video source into software at resolutions up to 1080p60}}
|-
| &lt;!--Description--&gt;Magewell USB Fusion 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|versatile USB video capture device that allows users to switch between two HDMI inputs and one USB webcam input for live presentations}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;ROLAND UVC-01 USB Video Capture
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2020  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Sunplus Innovation Technology Inc. MiraBox HSV321 ARX321 Video Capture device 
| &lt;!--Vendor ID--&gt;ox1bcf
| &lt;!--Product ID--&gt;0x2c99
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 uvc uac  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;UGREEN CM716 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| uvc uac but disable HDCP on your source device (PS4/PS5, Xbox) }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;VisionTek UVC HD60 Capture Card
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;Acer Aspire Crystal Eye AOA110 AOA150 0.3M 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2008 webcam }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;AVerMedia Live Streamer CAM 313 (PW313) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2019 uvc 1080p/30 webcam}}
|-
| &lt;!--Description--&gt;AVerMedia Live Streamer DUO 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2021 uvc 1080p/60 webcam}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;[http://reviews.cnet.co.uk/webcams/creative-live-cam-optia-af-review-49294183/ Creative Live Cam Optia AF] 2.0M
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| {{no|2008 }}
|-
| &lt;!--Description--&gt;DSLR macro extensions + a cheap 50mm E-Series lens + some PVC tubing and a negative holder 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes| if uvc camera chosen}}
|-
| &lt;!--Description--&gt;DSLR scanning using a macro lens, for the adapter, for a 3d printed negative holder) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{yes| if uvc camera used }}
|-
| &lt;!--Description--&gt;Logitech C270 
| &lt;!--Vendor ID--&gt;0x046d
| &lt;!--Product ID--&gt;0x0825
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|720p }}
|-
| &lt;!--Description--&gt;Logitech C910 C920 HD Pro 5Megapixels 720p 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|Output mjpg 1080p}} 
|-
| &lt;!--Description--&gt;Logitech C920s c922 HD Pro 5Megapixels 1080p 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|Output mjpg 1080p}} 
|-
| &lt;!--Description--&gt;Logitech 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|}}
|-
| &lt;!--Description--&gt;Logitech Brio 100 300 500 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|}} 1080p 
|-
| &lt;!--Description--&gt;Logitech MX Brio 4k 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|4k}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|}}
|-
| &lt;!--Description--&gt;Microsoft's LifeCam HD-3000 HD-5000 
| &lt;!--Vendor ID--&gt;0x045e
| &lt;!--Product ID--&gt; 0x0779
| &lt;!--Revision--&gt;1.06
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;Microsoft LifeCam Cinema 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;Microsoft LifeCam Studio 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}} sony imx179 1080p 
|-
| &lt;!--Description--&gt;Pi 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}} 1/2.8” Sony IMX291 image sensor, it's a 2MP, UVC-compliant, ultra-wide-angle, low light, high-speed USB 2.0 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}} OV5648 
|-
| &lt;!--Description--&gt;razer kiyo 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}} 4 megapixel sensor 1080p 30fps 720p 60fps - 12 led ring light adjustable 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;TeckNet C068 1.3mpixel HTD USB2.0 Camera Vimicro Z-Star Corp 
| &lt;!--Vendor ID--&gt;0x0AC8
| &lt;!--Product ID--&gt; 0x3420 
| &lt;!--Revision--&gt;0x01FA
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;YEALINK(XIAMEN) NETWORK UVC50 is compatible with the UVC 1.1 protocol CP960-UVC50 and CP960-UVC80 kits PTZ, CP960-UVC30 Kit is UVC 1.5 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID 
| Product ID
| Revision 
| Opinion 
|-
| &lt;!--Description--&gt;Amcrest ProHD 1080P WiFi Wireless IP Security Camera - 1080P (1920TVL), [https://www.ispyconnect.com/man.aspx%3Fn%3DAmcrest IP2M-841] nvr 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}} h264/rtsp, motion detection, features Sony image sensor and Ambarella processor - rtsp://[username]:[password]@[IPaddress]:[port]/cam/realmonitor?channel=[channel]&amp;subtype=[stream] - [username] - username to login to the DVR or NVR, [password] - password, [IPaddress] - IP address of the device. If you are not on the same local network, this should be the external IP address of the device's network, [port] - port number, [channel] - channel number of the stream, [stream] - view the Main or Sub stream. (main stream is 0, sub stream is 1) , eg. rtsp://admin:admin@192.108.1.108:80/cam/realmonitor?channel=1&amp;subtype=1 - utilizing RTSP ( rtsp://user:pass@ipcam1 )  
|-
| &lt;!--Description--&gt;Axis all modern ones 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}} RTSP/RTP + H264/mjpeg or MJPEG over HTTP
|-
| &lt;!--Description--&gt;PTZ 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;DLink DCS-5222 5222L network camera 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}} camera streams H.264 over RTP controlled by RTSP 
|-
| &lt;!--Description--&gt;Dlink DCS900 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;Sony 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;Wansview 1080p [http://marc.merlins.org/perso/linuxha/post_2013-11-10_Reviewing-IP-Webcams-for-Linux-and-Zoneminder_Dlink-DCS900_-Ubnt-Aircam_-Foscam-FI8904W-FI8910W_-FFI9820W_-FI9821W_-Wansview-NCB541W_-and-Zavio-F3210.html#NCM625GA NCM625GA] IP Camera WiFi Wireless IP Security Camera , Full HD Plug n Play Home Surveillance / Baby Monitor 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}} RTSP/RTP + H264/mjpeg - play its HD stream without problem with vlc rtsp://ip/live/ch0 and getting  jpegs http://ipaddr/mjpeg/snap.cgi?chn=0 - methods involve transcoding h.264 video from the camera into jpeg's, which is cpu intensive - able to pull images manually, using http://username:password@ip/mjpeg/snap.cgi - 
|-
| &lt;!--Description--&gt;Wansview NCB541W
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|}}
|-
|}


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc}}
|-
| &lt;!--Description--&gt;Avermedia Game Capture HD C281 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2011 standalone h.264 recording of up to component cable not hdmi but not uvc}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Avermedia GL310 Live Gamer Portable (LGP Lite)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2014 not working usb2 and USB Lite no uvc}} 
|-
| &lt;!--Description--&gt;Avermedia AVerMedia Live Gamer Portable ([https://github.com/Trouffman/octv_gears_lgp Model C875])  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2014 usb2 no uvc}}   
|-
| &lt;!--Description--&gt;AVerMedia LGX Live Gamer extreme GC550
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2015 but [https://github.com/ChrisAJS/lgx2userspace driver]}}
|-
| &lt;!--Description--&gt;AVerMedia LGX2 Live Gamer extreme2 gc550 plus gc551 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2017 but [https://github.com/ChrisAJS/lgx2userspace driver]}}
|-
| &lt;!--Description--&gt;Avermedia ExtremeCap UVC - BU110 
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2017 maybe not uvc and uac}}
|-
| &lt;!--Description--&gt;AVerMedia Live Gamer Portable 2 Plus GC513 Micro-USB Capture Box LGP2 Plus
| &lt;!--Vendor ID--&gt;0x07ca
| &lt;!--Product ID--&gt;0x1513
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2017 powered by a standard Micro-USB cable, video capture output up to 1080p60 capture to hdmi in, standalone sd card recording on exFAT or FAT32 of .MOV, 2160p pass-through hdmi out to tv - no vrr - [https://www.avermedia.com/uk/support/download#ans_part firmware latest 2.1.7.13, 2.1.7.14], SN74AVC8T245 8bit, DRV604 stereo, iTE IT6663FN hdmi 2.0 splitter, TLV320DAC3101 DAC, CS42L73 audio codec, CDCE913 PLL clock, W29N01HVSINA nand bios, I-Catch V35MA SOC CPU 32bit MIPS24K, ADV7480 hdmi mhl, }}
|-
| &lt;!--Description--&gt;AVerMedia Live Gamer 4K LG4K GC573 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2018 not uvc but [https://github.com/derrod/lg4k-linux drivers here], }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;Blackmagic intensity Extreme Capture Card
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2011 not uvc }}
|-
| &lt;!--Description--&gt;BlackMagic Intensity Pro 4k 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2015 }}
|-
| &lt;!--Description--&gt;Elgato Video Capture (1VC108601000)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;Elgato Game Capture 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc, mini usb}}
|-
| &lt;!--Description--&gt;Elgato Game Capture HD60 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc, }}
|-
| &lt;!--Description--&gt;Elgato Game Capture HD GCHD 2GC309901000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc https://github.com/tolga9009/elgato-gchd needs firmware mb86h57_h58_idle.bin and mb86h57_h58_enc_h.bin - mini usb}}
|-
| &lt;!--Description--&gt;Elgato HD60S Elgato Game Capture 4K60 S+ Video Capture 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|non uvc, }}
|-
| &lt;!--Description--&gt;August EZCap.tv model 116 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| }} poor audio recording 
|-
| &lt;!--Description--&gt;E-SDS Diamond Maplin 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;Hauppauge 1212 HD PVR 
| &lt;!--Vendor ID--&gt;0x2040
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| }} analog and component only - PlayStation (.m2ts), AVCHD (ts), or XBox(.mp4) recording formats - switched the component output from the default YPbPr to RGB. 
|-
| &lt;!--Description--&gt;Hauppauge 1431 1445 HD PVR Gaming Edition HDMI Capture 
| &lt;!--Vendor ID--&gt;0x2040
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2014 not working, can get warm}}  
|-
| &lt;!--Description--&gt;Hauppauge HD Rocket 
| &lt;!--Vendor ID--&gt;0x2040
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc}}
|-
| &lt;!--Description--&gt;Hauppauge HD-PVR2 (model 145210 Rev E4) 
| &lt;!--Vendor ID--&gt;0x2040
| &lt;!--Product ID--&gt;0xE502
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;Hauppauge 1480 1482 HD PVR 2 GE Gaming Edition HDMI Capture green LED - 1498 1503 1504 Plus version with Mac support 
| &lt;!--Vendor ID--&gt;0x2040 
| &lt;!--Product ID--&gt;0xe514 0xe524
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| can get warm - [https://ez.analog.com/video/w/documents/581/adv7482-design-support-files ADV7482] [https://patchwork.kernel.org/patch/9201075/ video chip] with Magnum DXT H.264 encoder blob, IDR keyframe generation poor - best for model 157210 and not 157221 and Game Edition Plus (model 157320) 2040:E505 E505-00-00AF1234 [http://www.hauppauge.com/site/support/linux.html#tabs-3 ]}} 
* HDMI: 1920x1080p50/60, 1920x1080i50/60, 1280x720p50/60, 720x480i, 720x576i, 640x480p60.
* Component: 1920x1080p50/60, 1920x1080i50/60*, 1280x720p50/60, 720x480p60, 720x480i, 720x576i.
* Composite: 720x480i and 720x576i 
* Audio Inputs : HDMI PCM and RCA support with Adjustable Bitrate Quality 2 Channel AAC/AC3 audio codec 
|-
| &lt;!--Description--&gt;Hauppauge 1512 HD PVR 2 PC blue LED with optical in input on the back 
| &lt;!--Vendor ID--&gt;0x2040
| &lt;!--Product ID--&gt;0xe525
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| }} can get quite warm - IR Blaster added - 
|-
| &lt;!--Description--&gt;Hauppauge Colossus2 E585-00-00AF4321 
| &lt;!--Vendor ID--&gt;0x2040
| &lt;!--Product ID--&gt;0xe585
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;Ion SLIDES2PC 35mm Portable Slide &amp; Film Scanner 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;Ion Pics 2 PC 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;ION PowerScan USB film and slide scanner
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2011 not uvc }}
|-
| &lt;!--Description--&gt;Koolertron Sunny 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;FilmScan35 35mm Film Negative Scanner 1304 marks spencer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;U3 HD Capture 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;[https://github.com/openrazer/openrazer Razer Ripsaw HD] Game Capture (RZ20-01780100)
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2017 not uvc put in usb2 slot and use video BGR3 (Emulated) and OpenRazer drivers }}
|-
| &lt;!--Description--&gt;Razer Ripsaw HD USB HDMI Capture Card 
| &lt;!--Vendor ID--&gt;0x1532
| &lt;!--Product ID--&gt;0x0d01
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2018 not uvc compliant}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;Silvercrest 35mm Photo Slide Scanner 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc but not great quality}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;Z-Star Microelectronics Corp. Traveler TV 6500 SF Dia-scanner
| &lt;!--Vendor ID--&gt;0x0ac8
| &lt;!--Product ID--&gt;0x3370
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2010 not uvc and poor scans}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| not uvc }}
|-
|}


=== AR VR XR Headset ===

 AROS needs realtime isochronous transfers in EHCI and XHCI, then an usb based uvc.class to vhi type driver for virtual display and maybe more 

The primary engineering challenge of VR is motion sickness caused by a mismatch of visual and inner ear information, which is extremely well established as causing people to throw up in a wide range of contexts outside of VR. The experiences that make some people sick are low framerate. Foveated rendering doesn't solve vergence accommodation. Your eye will still be focused at infinity regardless of where you are looking, you'll just have the illusion that the foreground or background are out of focus. Eye tracking plus dynamic lenses (perhaps liquid lenses) or real light fields are necessary. 

First start with apps that have simple static features at first, then advance to dioramasa and teleportation options for 10, 20 minutes and then gradually upgrade over a timespan of four weeks to train your brain. Avoid smooth motion stuff like rollercoaster or mountain heights until much later. Even with this preparation, VR makes 40% of people seasick nausea. If so, you may be able to use VR glasses just to watch videos and some slow moving apps [https://www.emuvr.net/ emuVR] instead.

*2014-2019 1st Gen, low resolution, 
*2020-2025 2nd Gen, higher resolution, 
*2026-

Most hardware typically has a 1-3 year retail lifespan with 1-3 years of updates after. Really need &quot;right&quot; tethered PCVR rather than wireless. 
The advantage to being tethered to a PC is processing power. Any standalone headset is going to be running purely off of batteries.

VR and AR are known as XR

Technology will get immersed enough so not making people sick. Higher resolution, faster frame rates, and [https://github.com/opentrack/opentrack better tracking]. 
Eventually, hyper reality brings VR, AR and MR digital layers together as a less chaotic, optic tracking with no delay, agents understanding, experiences with objects 

3Dgs 4Dgs gassian splats bullet time slice photo snaps .ply for WebXR 

[https://lvra.gitlab.io/docs/hardware/ ], 

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Big Screen Beyond 1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2023 pcvr 2560 x 2560, fixed IPD,  }}
|-
| &lt;!--Description--&gt;bigscreen Beyond 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 pcvr oled 5120 x 2560 @75Hz 2688x2688 @90Hz over pancake lenses, 116 FOV, virtual screens, custom facial plate from iphone app, streamvr 2.0 basestations and controllers not included, no passthrough, 107g-196g, }}
|-
| &lt;!--Description--&gt;bigscreen Beyond 2e 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 pcvr oled 5120 x 2560 total up to 90Hz pancake lens 116 FOV adjustable IPD app needed for adjustment, eye tracking, custom face mask cushion, streamvr 2.0 basestations and controllers not included, seperate head strap and speaker modules extra costs, 110g-300g }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Dpvr P1 Pro 4k Ultra Vr Headset 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 wireless snapdragon, }}
|-
| &lt;!--Description--&gt;DPVR P2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Play for Dream MR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 android modular 3840x3552 uoled per eye 90Hz or qled mura issues, Arm snapdragon XR2+ Gen 2, eye tracking and 11 cameras 7 sensors 22 ir leds 14ms latency and foveated rendering, 1.5hrs battery, }}
|-
| &lt;!--Description--&gt;Play for Dream GravityXR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 ultralight head gear gx100 3w }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }} 
|-
| &lt;!--Description--&gt;[https://lvra.gitlab.io/docs/community/ Valve Index HMD] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 tethered PC VR headset 1440 x 1600 120Hz, 108° and 104° FOV, fresnel lenses, SteamVR2 compatible tracking ir basestations, controllers aka Knuckles, dp 1.2 and usb3 cable proprietary cable end, no battery, }}
|-
| &lt;!--Description--&gt;Valve Steam Frame (Valve Deckard / Valve’s Index 2) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 - 2160 x 2160 up to 144Hz pancake lens, 108° and 96° FOV, wifi 6 fovelated streaming, Qualcomm Snapdragon 8 Gen 3 with [https://github.com/FEX-Emu/FEX fex] arm-to-x86 x64 translation layer, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Sony PSVR2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|2023 PCVR with adapter, two, one for each eye, 2000 x 2040 resolution OLED panels from 90Hz 120Hz refresh rates,  fresnel lenses, 116° and 102° FOV, sony proprietary headset cable end, needs additional comfort options, }}
|-
| &lt;!--Description--&gt;VisionPro
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Goertek glasses 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;HTC Vive ?
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| 2016 2x 1080x1200 needs external power supply, }} 
|-
| &lt;!--Description--&gt;HTC Vive Original 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2016 108° and 96° FOV}}
|-
| &lt;!--Description--&gt;HTC Vive Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2016 , uvc, at least 2 powered steamvr basestations so 3 to 5 wall warts in total, proprietary cable end, }}
|-
| &lt;!--Description--&gt;HTC Vive Pro 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2017 dual 1440x1600 oled displays, 116° and 100° FOV - steamvr 2.0 basestation 2 for 5m2 area 4 for 10m2 - steamvr 2.0 joypads - low latency wireless later - type USB-c headphone adapter required, [https://github.com/CertainLach/VivePro2-Linux-Driver Rust on Linux] with [https://github.com/santeri3700/vive-pro-2-on-linux Shell], proprietary cable end, }} 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Lynx R1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2023 android Qualcomm Snapdragon XR2 Gen 1, }}
|-
| &lt;!--Description--&gt;Lynx R2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2026 company liquidated, 2 x 2312x2160 110 FOV pancake lenses, LynxOS android Qualcomm Snapdragon XR2 Gen, openxr 1.1, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Oculus Rift prototype development kit [https://www.virtual-boy.com/forums/t/the-oculus-rift-dk1-thread/ DK1] with [https://www.youtube.com/watch?v=X_T4DJyy2Bo wired razer hydra controllers]
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2013 pcvr LCD 1280 × 800 resolution 640 × 800 per eye up to 110° FOV, and 3DoF rotational tracking via a 1000Hz 9-axis IMU (Accelerometer, gyroscope, and magnetometer), no positional optical tracking either inside-out or outside-in, 380g, nausea issues, , }}
|-
| &lt;!--Description--&gt;Oculus Rift prototype development kit [https://github.com/facebookarchive/RiftDK2/tree/master DK2], [https://www.ifixit.com/Teardown/Oculus+Rift+Development+Kit+2+Teardown/27613 ifixit teardown] 
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2014 pcvr, 5.7&quot; Super AMOLED display with a resolution of 960 x 1080 per eye 100° field of view, 1 usb Positional Tracker DK2 camera, lots of wires}}
|-
| &lt;!--Description--&gt;Facebook [https://github.com/thaytan/OpenHMD/tree/rift-kalman-filter Oculus Rift CV1] [https://noraisin.net/diary/?m=202201 some Linux support] [] [https://github.com/OpenHMD/OpenHMD/issues/330 AMD usb issues] [https://github.com/OpenHMD/OpenHMD/wiki/Xorg ] [https://github.com/Doc-Ok/OculusRiftCV1Camera Live Video] [https://www.youtube.com/@thaytan Youtube] [https://github.com/Fredrum/riftOnLinux Pi] [https://github.com/OhioIon/riftDriverPi ], but not quite there with the [https://www.youtube.com/watch?v=DSsCN6HFkWc consumer CV1], [https://forum.dcs.world/topic/142259-cv1-not-working-in-dcs/#comment-2878168 orange led could be HDMI Signal is not within HDMI Spec and might be Overclocked or usb3 not getting enough power frustrating],  
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;0x3031, 0x2031, 0x0031 and 0x0211 for 3p-a basestations lighthouses, 0x045e 0x02e6 for xbox wireless adapter 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2016 powered run from your PC maybe uvc via wired dual PenTile OLED 2160x1200 (1080x1200 per eye) @ exactly 90Hz but screen door effect (space between pixels), 87 FOV, IPD from 58mm to 72mm, good 3D audio and okay mic, constellation headset 6DOF (3-axis rotational tracking + 3-axis positional tracking) with up to 3 usb infrared basestation (1 in front and 2 behind pointing upwards) on usb3 and usb2 to your PC but the tracking can be fragile so set it up on a weekly basis, wired only HDMI 1.3, USB 3.0 bus powered with proprietary plug in headset, 470g 1lb front heavy, 2 robust 1st Gen touch controllers with external sensors i.e. outside-in - 1 aa alkaline over rechargable battery each , press occulus and B buttons for 2 secs to connect, headset traps air so gets very warm inside and random disconnects due to twisting action on the top of the headset and/or cables, t4 torx screws }} 
|-
| &lt;!--Description--&gt;Facebook Occulus Go 32Gb 
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2018 discontinued 2020 android based, 1280x1440 per eye 60Hz LCD, not gaming, no inside-out and limited self tracking, }} 
|-
| &lt;!--Description--&gt;Facebook Oculus Rift S [https://noraisin.net/diary/?m=202201 some Linux support] 
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;0x0051 headset (cdc, audio, tracking data), 0x2052 usb hub, 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2019 PCVR wired dual LCD 1080 by 1200, 88 horizontal FOV, display port (fibre optic strands) and annoying USB3 copper cables (power, audio and other data) but proprietary port in the headset, cameras on the headset (&quot;inside-out&quot;) tracking so no base stations, non removeable head band and cushions and ipd hard to set, requires specific fragile Rift S/Quest1 2nd Gen Touch controllers which has a ring of translucent plastic with leds inside - t5 torx to disassemble for sticks drifting}} 
|-
| &lt;!--Description--&gt;Facebook Occulus Quest 1 
*032Gb
*064Gb
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;0x0183 (single adb boot), 0x0
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2019 android standalone wireless, 1440 x 1600 72Hz oled, front heavy though, play area 2m x 2m or bigger, low clocked Qualcomm Snapdragon 835 (MSM8998) (4x Kryo 280 Gold cores ARM Cortex-A73) + (4x Kryo 280 Silver A53), 2 to 3 hrs play time, 575g, 2nd Gen touch controllers, }}
|-
| &lt;!--Description--&gt;Meta Oculus Quest 2 KW49CM aka Codename Del Mar [https://www.meta.com/en-gb/help/quest/967070027432609/ fragile 3rd Gen Touch controllers] [https://www.youtube.com/watch?v=Cgejky8ZeoM internal battery] and selling over 20 million, more than all other quest headsets combined 
*064Gb 
*128Gb (110Gb free) 
*256Gb 
Setup continuous wifi, create Meta Oculus account, [https://developers.meta.com/horizon/ verify dev account, click on My apps], [ create Organization -&gt; My Organization Groupings], [https://www.youtube.com/watch?v=QPInS5xxF-0 finally, meta quest mobile app to switch on adb], 
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;0x5010 (), 0x0083 (massstorage), 0x0086 (), 0x0186 (adb and xrsp [https://github.com/shinyquagsire23/xrsp_tests tests]), 0x0090 (composite adb), 0x0081 (), 
| &lt;!--Revision--&gt;0419
| &lt;!--Opinion--&gt;{{unk|2021 android stand alone, lcd 1832x1920 per-eye 90Hz refresh rate, 97 FOV, fresnel lenses, 6DOF (degrees of freedom), 58-63-68 IPD settings, low clocked Arm snapdragon xr2 gen 1 apps with Meta Link cable USB-C usb3.2 pcvr maybe, b/w but no color passthrough, 6 t2 torx and 5 ph00 screws in headset (long bit), discontinued December 31, 2024, feature updates until December 2026, critical bug fixes and security updates until December 2027, 470g, Oculus + B button on right controller (move) and Menu + Y button on left controller (click) for about 3 seconds, 10W 5v 2a, RTL8153 chipset usb support, 
*V60 unable to 
*V77 pcvr issues 
*V79 unable to }}
|-
| &lt;!--Description--&gt;Facebook Occulus Quest Pro aka Codename Seacliffe 
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2022 android standalone wireless 1440 x 1600 72Hz oled, 106° and 96° FOV mini lcd local dimming, pancake lenses, limited eye tracking, play area 2m x 2m or bigger, higher clocked snapdragon xr2 gen 1 arm cpu Arm apps, 1 to 2 hrs play time, new pro controllers with 3 cameras each, battery at rear, wireless charging, color passthrough, 9V 3A or 5V 3A, 
*v77 capped wifi }}
|-
| &lt;!--Description--&gt;Meta Oculus Quest 3 aka Codename Eureka [ Air Light ALVR] or [ WiVRn] with fragile touch plus q3 controllers 
*128Gb
*512Gb
streaming from PC with [https://github.com/alvr-org/Monado-ALVR ALVR], runtime of [https://monado.freedesktop.org/ Monado steamvr alternative openxr openVR], with Envision GUI, 
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2023 standalone, pancake lenses on lcd 2064 x 2208 res panel per eye 1200ppi - 104° and 96° FOV - up to 120Hz, Arm snapdragon xr2 gen 2 apps,  foveated rendering, Meta Link cable USB-C 3.2, headstrap clamshell or halo style, speaker arms fragile, color passthrough, 510g, 18W 9v 2A or 15W 5V 3A, 
*v74 ok }}
*v76 pcvr issues }}
|-
| &lt;!--Description--&gt;Meta Quest 3S aka Codename Ventura 
*128Gb
*256Gb
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 Arm snapdragon xr2 gen 2 cpu, lcd 1832 x 1920 fresnel lenses, 97 FOV, headphone arms fragile, better air flow, no promixity sensor inside, Meta Link cable USB-C 3.2, passthrough, }}
|-
| &lt;!--Description--&gt;Meta Boba 3 
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2027 ultra-wide 180° x 120° FOV, snapdragon XR2 G2,  }}
|-
| &lt;!--Description--&gt;Meta Tiramisu 
| &lt;!--Vendor ID--&gt;0x2833
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2027  µOLED displays with 90 pixels per degree,  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Pimax 5K Super Plus 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 }}
|-
| &lt;!--Description--&gt;Pimax 8K
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2020  }}
|-
| &lt;!--Description--&gt;Pimax 8K-X 8KX 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021  }}
|-
| &lt;!--Description--&gt;Pimax Crystal Light 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 tethered to PC with 2160 x 2160 4k 120Hz, 115° and 96° FOV, inside-out tracking, no battery, display port cable, variable qc and customer service, }}
|-
| &lt;!--Description--&gt;Pimax Crystal Super 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 tethered to PC with 3640 x 3640 4k 90hz, 116°+ and 100° FOV,  eye tracking, inside-out tracking, no battery, display port cable, }}
|-
| &lt;!--Description--&gt;Pimax Dream Air with Lighthouse(s)  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 tethered 3840 by 3552 @90Hz micro oled with pancake lens, 100 HFOV 96 VFOV but FOV IPD changes in app, link box for headset 2 split y cables, removable face gasket, 290g, steamVR2 bases and controllers, eye tracking, }}
|-
| &lt;!--Description--&gt;Pimax Dream Air SLAM 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026  Simultaneous Localization and Mapping (SLAM) tracking inside-out so no base stations,  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;[https://somniumspace.com/ Somnium VR One VR1] [https://portal.vrgineers.com/user-guide/software/ open source] VR headset
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 pcvr 2880 x 2880 per eye @90 @120Hz, 125° horizontal 100° vertical FOV, 2 x SteamVR 2.0 bases, passthrough, 900g }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Varjo Aero VR-1 Headset 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 psu needed, 2 x Mini LED binocular of 150 nits, 2880x2720 per, 90Hz, FOV 102° horizontal, 73° vertical, 720g with headstrap, 2 x SteamVR 2.0 basestations, no speakers/mic, hdmi and usb3.0}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Varjo Aero XR-3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Varjo Aero XR-4 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Camelo La Melaza Music Shield 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2026 no usb only bluetooth ,  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;InAir 2 elite suite 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 ar  nits 46FOV , , 4h battery life, 80g, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Oakley Vanguard 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;RayNeo Air 3s 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 AR 100in 46FOV 650nits, usb-c 79g  }}
|-
| &lt;!--Description--&gt;RayNeo Air 3S Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 AR 135in virtual display 46FOV 1200nits, usb-c 80g }}
|-
| &lt;!--Description--&gt;RayNeo Air 4 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 AR oled vision 4000 processing, HDR10, 47 FOV }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Rokid Max 2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 ar 147in 50 FOV 650nits, usb-c back left, 76g, }}
|-
| &lt;!--Description--&gt;Rokid AI Spatial with Station 2 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 AR 600nits 147in 50FOV  75g, }}
|-
| &lt;!--Description--&gt;Rokid 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| ar ai smart glass}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Viture Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 135in 46 FOV 1000nits, magnetic connector, 77g, }}
|-
| &lt;!--Description--&gt;VITURE XR Luma 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 ar 147in 1200p 50 FOV, }}
|-
| &lt;!--Description--&gt;Viture Luma Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 152in 52 FOV 1000nits 1200p, 3dof, , 79g, }}
|-
| &lt;!--Description--&gt;Viture Luma Ultra 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 in  FOV, 2 cameras, 3dof 6dof,  }}
|-
| &lt;!--Description--&gt;[https://github.com/wheaney/XRLinuxDriver Viture Luma Pro] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Viture Beast 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 ar 1250nits 58FOV 174in, magnetic,  88g,  }}
|-
| &lt;!--Description--&gt;VITURE Beast X Glasses models (Immersive 3D Moonlight) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 based 2D to 3D conversion with support DP Alt Mode (DisplayPort over USB-C), 1200p, 3df tracking, practic lenses 58deg POV, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Xreal One 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 ar 600nits, 50FOV, 3dof, usb-c 84g,  }}
|-
| &lt;!--Description--&gt;XReal One Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 ar 700nits 57FOV 171in, usb-c, x1 3dof, }}
|-
| &lt;!--Description--&gt;Nreal now Xreal Air 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 , micro-oled 1080p, audio, virtual uvc ar displays, }}
|-
| &lt;!--Description--&gt;Nreal now Xreal Real3D 1S 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 AI based 2D to 3D conversion 57 FOV, , virtual uvc ar displays not vr, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Xiami XR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Xtal 8k
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;Apple Vision Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2022 tethered AR mixed reality glasses,   3300ppi, 800g, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Google XR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;HTC Vive Focus 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 standalone }}
|-
| &lt;!--Description--&gt;HTC Vive Focus Plus 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 android with 2 1440 x 1600 75Hz amoled, inside-out, durable motion controllers, Vive port,  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;HTC Vive Pro EYE 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2019 dual-OLED displays 2880 x 1600 combined resolution), SteamVR 2.0 tracking, foveated rendering, Tobii, it enables gaze-based menu navigation with avatar eye contact, proprietary cables, }}
|-
| &lt;!--Description--&gt;HTC Vibe Cosmos 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2018  poor tracking and lifespan on controllers,  }}
|-
| &lt;!--Description--&gt;HTC Vibe Cosmos Elite 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2020 1440x1700 per eye resolution, 90 Hz refresh rate, 6 DoF tracking, 2880 x 1700 combined pixel resolution, 97° FoV, two controllers and two base stations. Lighthouse tracking, }}
|-
| &lt;!--Description--&gt;HTC Vive Focus Vision Wired 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No| }}
|-
| &lt;!--Description--&gt;HTC Vive Focus 3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2021 per-eye resolution of 2448×2448 at 90 Hz, a 120-degree field of view, Qualcomm Snapdragon XR2 Gen 1,  }}
|-
| &lt;!--Description--&gt;HTC Vive XR Elite VR Headset Deluxe Pack 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2022 snapdragon xr2 gen 1, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Pico Goblin 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2017 android based, 2.5K 1280x1440 per eye @70Hz, 92° FoV, and 3DoF (three degrees of freedom) tracking (Orientation tracking only—yaw, pitch, roll), single controller, snapdragon 820, ipd adjustment 54-71 mm, 600g,  }}
|-
| &lt;!--Description--&gt;ByteDance Pico G2 4K
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2020 android standalone VR headset, 3840 x 2160 (4K) LCD screen, Snapdragon 835 processor, 3DoF so rotational movement (looking around, pointing) rather than positional movement (walking, leaning), does not support hand or eye tracking, 800g }}
|-
| &lt;!--Description--&gt;ByteDance Pico NEO 2 EYE
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2020 6DoF 360g snapdragon 845 display 4k 75Hz tracking inside-out - magnetic field for controllers - pico software on android 8 - eye tracking }}
|-
| &lt;!--Description--&gt;ByteDance Pico Neo 3 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 Snapdragon XR2 Gen, 4K 3664 x 1920 90Hz lcd, battery at rear, displayport, Pico apparently emulates Oculus controllers, }}
|-
| &lt;!--Description--&gt;ByteDance Pico Neo 3 Pro 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 }}
|-
| &lt;!--Description--&gt;ByteDance Pico Neo 3 Link 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022 }}
|-
| &lt;!--Description--&gt;ByteDance Pico 4 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2023 2160x2160 panel per eye 75Hz 90Hz 105 FOV, Arm snapdragon xr gen 1, }}
|-
| &lt;!--Description--&gt;ByteDance Pico 4 ultra 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2023 2160 x 2160 @90 105 FOV, snapdragon XR2 G2, streaming from PC with alvr, wireless streaming from PC with WiVRn, Pico apparently emulates Oculus controllers, not plug and play, }}
|-
| &lt;!--Description--&gt;ByteDance Pico 5 aka Project Swan aka Vision Pro Competitor 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 micro-oled BOE 3840 x 3840 4000ppi per eye, MLA pancake lenses, custom pico arm cpu, pico os 6 android, eye and hand tracking, 300g,  }}
|-
| &lt;!--Description--&gt;ByteDance Pico  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Samsung Galaxy XR VR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 3552 x 3840 @60-90 109 FOV , Arm snapdragon XR2+ Gen 2, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Shiftall MeganeX 8K 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2024 android  }}
|-
| &lt;!--Description--&gt;[https://en.shiftall.net/products/meganex8k MeganeX Superlight 8K] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 android (3552 x 3840 pixels) into pixel count yields 27.27MP 10-bit HDR-compatible 4K resolution micro OLED panels @90Hz, pancake lenses 94 FOV, SteamVR™ tracking, 180g, 5V 2A, }}
|-
| &lt;!--Description--&gt;[https://en.shiftall.net/products/meganex8kmk2 MeganeX 8K Mk2 MkII] [https://github.com/sboys3/CustomHeadsetOpenVR community] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 pcvr linux, 4K per eye (1.35inch micro OLED 3552x3840 10 bit HDR) 27MP @90Hz 75Hz 72Hz pancake, upto 108 hor 100 vert FOV, usb-c and dp cables to breakout box, 5V 2.1A, 200g}}
|-
| &lt;!--Description--&gt;Shiftall 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2026 }}
|-
| &lt;!--Description--&gt;Shiftall 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;Acer Windows(TM) MR AH101 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 Dual 2.89” LCD panels 2880 x 1440 combined (1440 x 1440 per eye) Up to 90Hz (HDMI 2.0), or 60Hz (HDMI 1.4), Field of View FOV 95, Tracking Inside-out, lots of light leak, }} 
|-
| &lt;!--Description--&gt;Acer H7001 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2017 wmr 1440 x 1440 per-eye resolution @90Hz refresh rate, and 100-degree field of view FOV, inside-out tracking with front-mounted cameras so no external sensors, flip-up visor design but has a &quot;screen door effect,&quot; subpar foam padding, win10 to win11 24H2,  }}
|-
| &lt;!--Description--&gt;Dell Visor Mixed Reality VRP100 VR118
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2017 2x 1440x1440 a bit of nose light leak }}
|-
| &lt;!--Description--&gt;Fujitsu 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2017 cheap and lots of light leak }}
|-
| &lt;!--Description--&gt;[https://github.com/HadesVR HadesVR] with [https://github.com/ManoloMancelli/Persephone-Classic-Controller Persephone Controller]
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;[https://www.youtube.com/watch?v=HFaVjB1uNOM Persephone 3 Pro DiY 6Dof SteamVR Headset], 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;HP Reverb G1 VR1000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 WMR 2160 x 2160 @90Hz, 115 FOV, , hp proprietary headset cable end, 2 camera tracking but poor and controllers can be unresponsive, 500g front heavy, flight sims rather than gaming,  }}
|-
| &lt;!--Description--&gt;HP 1440p Spatial Computing 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 dim display }}
|-
| &lt;!--Description--&gt;[https://forums.x-plane.org/forums/topic/294764-vr-in-linux-without-steam/ HP Reverb G2] WMR VR3000 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2020 2 2160 x 2160 90Hz, needs Windows10 or Win 11 24H2, 4 camera tracking, controllers can be unresponsive, hp proprietary headset cable end, , }} 
|-
| &lt;!--Description--&gt;HP 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Mirage Solo is a Standalone VR headset
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 Qualcomm Snapdragon 835, 1280x1440 per eye resolution, 75 Hz refresh rate, }}
|-
| &lt;!--Description--&gt;Lenovo Explorer VR2511N (G0A2) VR windows mixed reality (WMR) 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 LCD 2.89&quot; 1440 x 1440 per eye @90Hz, 6 DOF position tracking, 400g, }}
|-
| &lt;!--Description--&gt;[https://github.com/relativty/relativty open source relativty] 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Samsung MHD Odyssey XE800ZAA WMR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2018 9V 500mA oled screens 2x 1440x1600 with usb3 and hdmi cables but bluetooth dongle required }}
|-
| &lt;!--Description--&gt;Samsung MHD Odyssey+ Plus WMR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2019 dual 3.5-inch AMOLED displays 2880 x 1600 total @90Hz, 6DOF inside-out tracking with usb3 and hdmi cables but bluetooth dongle required, use only win10 or win11 24H2,  }}
|-
| &lt;!--Description--&gt;Sony PSVR 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2016 2x 1080x960 up to 120Hz, lots of cables and computation brick, sony camera needed for tracking, ps4 or move controllers, }} 
|-
| &lt;!--Description--&gt;Virtuality 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|1992 , , Amiga 3000 with TI chips, }}
|-
| &lt;!--Description--&gt;Virtuix Omni 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2013 VR treadmill changed course to commercial VR and pivotted back again 2020, }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


=== HDMI CEC transmitter and receiver ===

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


=== TV Remote Control MCE IR transmitter and receiver ===

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Compro K100 K300
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|need extra software support}}
|-
| &lt;!--Description--&gt;Elitegroup Computer Systems
| &lt;!--Vendor ID--&gt;0x1019
| &lt;!--Product ID--&gt;0x0f38
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;GMYLE MCE 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{Maybe|acts as usb-hid with limited keyboard like controls }}
|-
| &lt;!--Description--&gt;Hauppauge WinTV-PVR kit
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|untested}}
|-
| &lt;!--Description--&gt;Logitech Harmony 300 i300 600 650 800 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|need extra software support}}
|-
| &lt;!--Description--&gt;Microsoft MCE Commander 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|2005 need extra software support}}
|-
| &lt;!--Description--&gt;Microsoft 1039 rev 1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2005 home top of square shape direction keys}}
|-
| &lt;!--Description--&gt;Microsoft 1039 rev 2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2006 home under circle spaced direction keys}}
|-
| &lt;!--Description--&gt;Microsoft 1069 SMK Manufacturing, Inc
| &lt;!--Vendor ID--&gt;0x0609
| &lt;!--Product ID--&gt;0x0334 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2007 untested}}
|-
| &lt;!--Description--&gt;Philips RC1974506/00 
| &lt;!--Vendor ID--&gt;0x0471
| &lt;!--Product ID--&gt;0x0815
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|untested}}
|-
| &lt;!--Description--&gt;Sony RM-MCE10E PC REMOTE CONTROL VGN-AR21M VGX-XL100 VGN-AR21B/AR21S 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Sony RM-MCE20E PC REMOTE CONTROL
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Sony RM-MCE30E PC REMOTE CONTROL VGN-AW21XY VGX-TP3E VGX-TP3G 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Sony RM-MCE50E PC REMOTE CONTROL VGC-LA2R 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;TSDX-IR14 USB MCE Media Center External Infrared IR Receiver
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;chipsets support CIR (consumer IR) Winbond W83977F/AF, SMC IrCC 2.0 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|technical reasons it's not possible to use USB IrDA dongles}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| &lt;!--Description--&gt;Zotac RC2604323/01G Zbox Media Remote Control with IR USB Receiver OVU710
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
|}


{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;Anycubic Cobra 2 Max 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Bambu Labs A1 Mini 3D printer 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{No|2019 EMS proprietary slicer app and cloud use, eSUN}}
|-
| &lt;!--Description--&gt;Bambu Labs X1 Carbon 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2022  }}
|-
| &lt;!--Description--&gt;Bambu Labs X2D 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Creality K1
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Creality K2
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Creality 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Elegoo 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Lulzbot 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Prusa 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt; 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt; 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Qidi 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Snapmaker U1 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk|2025 tool changer  }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;Sovol SV08 Max
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| open source voron model, }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;desktop pick and place machines AFARCO PNP running OpenPnP for Desktop SMT 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|}


==ethwrap.class - Host Data Link &quot;Cable Bridge&quot; for data transfer==

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Advance USBNET (eTEK design)
| 0x0525
| 0x9901
| 
| {{N/A|untested}}
|-
| ALi Uli M5632 (chip)
| 
| 
| 
| {{N/A|untested}}
|-
| Aten (Ali Corporation) UN201
| 0x0402
| 0x5632
| 
| {{maybe|force binding from rawwarp to ethwrap}}
|-
| Belkin (eTek design see below)
| 0x050d
| 0x0004
| 
| {{N/A|untested}}
|-
| Digitus DN-3004 - USB Host Link
| 
| 
| 
| {{yes|works}}
|-
| EPSON USB client
| 0x0525
| 0x2888
| 
| {{N/A|untested}}
|-
| eTEK
| 0x056c
| 0x8100
| 
| {{N/A|untested}}
|-
| KC-190
| 0x050f
| 0x0190
| 
| {{N/A|untested}}
|-
| GeneSys GL620USB
| 
| 
| 
| {{no|no driver the half-duplex GL620USB is NOT supported, products using it include the Inland Pro USB Quick Link}}
|-
| GeneSys GL620USB-A
| 
| 
| 
| {{N/A|untested}}
|-
| Laplink Gold (uses NetChip 1080)
| 
| 
| 
| {{N/A|untested}}
|-
| Prolific 2301/2302 (Jaton USB ConNET) (BAFO DirectLinq) 
| 0x067b
| 0x0000 and 0x0001
| 0x0004
| {{maybe|detected but untested}}
|-
| Xircom PGUNET (uses AnchorChips 2720)
| 0x0547
| 0x2727
| 
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
|}

==cdcacm.class - USB modem==

The CDC ACM driver exposes the USB modem as a virtual serial modem or a virtual COM port to the operating system. The driver enables sending both data and AT commands, either through ACM (separating data and AT commands over different channels) or through Serial Emulation (passing the AT commands as is and as part of the data stream).

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Alcatel OT-I650 
| 0x1bbb
| 0x0003
| 
| {{N/A|untested}}
|-
| Acatel Dymamode/Dynamite
| 0x06b9
| 0xa5a5
| 
| {{N/A|untested Zyxel Prestige 630-13 - untested PROLiNK Hurricane 8000 external link }}
|-
| AnyData ADU-100A ADU-E100A ADU-E100D ADU-E100H D10
| 0x16d5
| 0x6501
| 
| {{N/A|untested}}
|-
| AnyData ADU-310
| 0x16d5
| 0x650
| 
| {{N/A|untested}}
|-
| AnyData ADU-500A ADU-510A ADU-510L ADU-520A
| 0x16d5
| 0x6502
| 
| {{N/A|untested}}
|-
| AnyData ADU-610 ADU-620
| 0x16d5
| 0x650
| 
| {{N/A|untested}}
|-
| BT On-Air USB MODEM 
| 0x079b
| 0x000f
| 
| {{N/A|untested}}
|-
| Conexant USB MODEM CX93010 
| 0x0572
| 0x1321
| 
| {{N/A|untested}}
|-
| Conexant USB MODEM RD02-D400 
| 0x0572
| 0x1324
| 
| {{N/A|untested}}
|-
| Conexant Chipset 
| 0x06ea
| 0x0002
| 
| {{N/A|untested AUS N367 Roadster II 56 USB (Model AM5050R3) - untested }}
|-
| [http://accessrunner.sourceforge.net/ Conexant AccessRunner]
| 0x0586
| 0x330a
| 
| {{N/A|untested }}
|-
| Creative Modem Blaster USB DE5670
| 0x1690
| 0x0101
| 
| {{N/A|untested}}
|-
| FIREFLY, MediaTek Inc
| 0x0e8d
| 0x0003
| 
| {{N/A|untested}}
|-
| Huawei E122
| 0x12d1
| 0x1446
| 
| {{yes|works}} [http://aros-exec.org/modules/newbb/viewtopic.php?post_id=49126#forumpost49126]
|-
| Huawei E160, E160E, E160G
| 0x12d1
| 0x1003
| 
|{{yes|works}} [http://aros-exec.org/modules/newbb/viewtopic.php?post_id=51888#forumpost51888] (Chipset: Qualcomm MSM6246)
|-
| Huawei E169 also known as Vodafone K3715 and Huawei K3715 
| 0x12d1
| 0x1001
| 
|{{yes|works}} [http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=4941&amp;forum=4&amp;post_id=44683#forumpost44683] (Chipset: Qualcomm MSM7200)
|-
| Huawei E220 &quot;Vodafone EasyBox II&quot; &quot;T-Mobile wnw Box Micro&quot; also known as Huawei K3565 
| 0x12d1
| 0x1003
|
| {{yes|works, see E169 above (Chipset: Qualcomm MSM6280)}}
|-
| Huawei E1750
| 0x12d1
| 0x1001
| 
| {{N/A|untested (Chipset: Qualcomm MSM6290)}}
|-
| Huawei E170, E172, E176 
| 0x12d1
| 0x1003
| 
| {{N/A|untested (Chipset: Qualcomm MSM7200)}}
|-
| Huawei E180
| 0x12d1  
| 0x1406
| 
| {{yes|Works (Chipset: Qualcomm MSM7200)}}
|-
| KYOCERA AH-K3001V 
| 0x0482
| 0x0203
| 
| {{N/A|untested}}
|-
| LG CU515
| 
| 
| 
| {{N/A|untested}}
|-
| MediaTek Inc GPS 
| 0x0e8d
| 0x3329
| 
| {{N/A|untested}}
|-
| Metricom GS Modem 
| 0x0870
| 0x0001
| 
| {{N/A|untested}}
|-
| Motorola MOTOMAGX phones 
| 0x22b8
| 0x6425
| 
| {{N/A|untested}}
|-
| Motorola Q Phone 
| 0x22b8
| 0x7000
| 
| {{N/A|untested}}
|-
| Hummingbird huc56s (Conexant) 
| 0x0572
| 0x1329
| 
| {{N/A|untested}}
|-
| Netcomm Roadster II 128 ISDN
| 
| 
| 
| {{N/A|untested}}
|-
| Nokia n70 N95 HSDPA
| 
| 
| 
| {{yes|works - see [http://aros-exec.org/modules/newbb/viewtopic.php?start=0&amp;topic_id=4415&amp;viewmode=flat&amp;order=ASC here]}}
|-
| OGO
| 0x045E
| 0x0079
| 0090
| {{no|no driver}}
|-
| Olitec ADSL Modem V2 
| 0x08e3
| 0x0100 / 0x0102
| 
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;Onda PT502HS 
| &lt;!--Vendor ID--&gt;0x19D2
| &lt;!--Product ID--&gt;0x0001
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
| Radicom V92HU-E2
| 
| 
| 
| {{N/A|untested}}
|-
| &lt;!--Description--&gt;Samsung i8510 Innov8 Symbian smartphone
| 0x04e8
| 0x6651
| &lt;!--Revision--&gt;
| {{yes|works}} [http://aros-exec.org/modules/newbb/viewtopic.php?start=0&amp;topic_id=5552&amp;viewmode=flat&amp;order=ASC&amp;type=&amp;mode=0] 
|-
| Samsung Tocco Lite (aka GT-S5230)
| 0x04e8
| 0x6795
| &lt;!--Revision--&gt;
| {{yes|works}} [http://aros-exec.org/modules/newbb/viewtopic.php?start=0&amp;topic_id=5552&amp;viewmode=flat&amp;order=ASC&amp;type=&amp;mode=0] 
|-
| Shiro / Aztech USB MODEM UM-3100 
| 0x0572
| 0x1328
| 
| {{N/A|untested}}
|-
| ZyDAS 56K USB MODEM 
| 0x0ace
| 0x1602
| 
| {{N/A|untested}}
|-
| ZyDAS 56K USB MODEM 
| 0x0ace
| 0x1608
| 
| {{N/A|untested}}
|-
| ZyDAS 56K USB MODEM - new version 
| 0x0ace
| 0x1611
| 
| {{N/A|untested}}
|-
| Zoom Telephonics Model 3095F USB MODEM 
| 0x0803
| 0x3095
| 
| {{N/A|untested}}
|-
| Ugobe Pleo
| 0x6962
| 0x0100
| 0x0100
| {{Yes|Works}}
|}


==Misc==

palmpda.class - no [http://aminet.net/package/util/libs/PdaLinkPoseidon pdalink.library and tools] in AROS 

 Palm PDA (discontinued) synchronisation requires a port of pdalink.library and its tools through virtual usbpalm.device.

{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Palm IIIx (OS3.1) serial rs-232 only
| 
| 
| 
| {{no|no }}
|-
| Palm IIIc (OS3.5)
| 
| 
| 
| {{no|no }}
|-
| Palm V
| 
| 
| 
| {{no|no }}
|-
| Palm m100
| 
| 
| 
| {{no|no }}
|-
| Palm m125 first USB - last with aaa batteries
| 
| 
| 
| {{no|no }}
|-
| Palm m500 (OS4)
| 
| 
| 
| {{no|no }}
|-
| Tungsten T (OS5) first arm cpu 
| 0x
| 0x
| 0x
| {{no|no }}
|-
| Zire 31 (OS 5.28) color arm-based
| 
| 
| 
| {{no|no }}
|-
| [[:w:Handspring (company)|Handspring Visor]] – USB support out of box
|
|
|
| {{no|no }}
|-
| Handspring Treo 600 – last one for [[:w:Handspring (company)|Handspring]] 
| 
| 
| 
| {{no|no }}
|-
| Treo 700w
| 
| 
| 
| {{no|no }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
|}


bluetooth.class - needs Bluetooth (Viking King Harald &quot;Bluetooth&quot; Gormsson (Old Norse: Haraldr Blátǫnn Gormsson; Danish: Harald Blåtand Gormsen) stack to work (not written due to licensing fees to use the symbol merging the Younger Futhark runes for H (ᚼ) and B (ᛒ), representing Harald's initials)
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
|}


ccid.class - Chip/Smart Card Interface Devices (not implemented)
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;cyberJack RFID basis
| &lt;!--Vendor ID--&gt;0x0C4B
| &lt;!--Product ID--&gt;0x9102
| &lt;!--Revision--&gt;0001
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{no|no driver}}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{N/A|untested}}
|-
|}


dfu.class - DFU firmware upgrade
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| &lt;!--Description--&gt;iPhone 3, 4, 5, 5c 
| &lt;!--Vendor ID--&gt;0x05ac
| &lt;!--Product ID--&gt;0x1290 0x1292 0x1294
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 32bit use with caution could cause damage}}
|-
| &lt;!--Description--&gt;iPhone 5s, 6, 7, 8, X 
| &lt;!--Vendor ID--&gt;0x05ac
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| 64bit use with caution could cause damage}}
|-
| &lt;!--Description--&gt;M-Audio/Midiman USB audio
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt;
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|- style=&quot;background:lightgrey; text-align:center; font-weight:bold;&quot;
| Description
| Vendor ID
| Product ID
| Revision
| Opinion 
|-
| &lt;!--Description--&gt;iPad 1, iPad 2 A1395 A1430, iPad 3, ipad mini A1432, iPad A1458 4th Gen (MD512LL/A),  
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2008-2013 32bit A4, A5 up to Apple A6X, iOS 1 to 10, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|-
| &lt;!--Description--&gt;iPad Air (1st generation) A1474, A1475, A1476, 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2014-2015 [https://github.com/AsahiLinux 64bit], A7, iOS 11 up to 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2015 64bit A8, A8X, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2016 64bit A9, A9X, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2017 64bit A10, A10X, 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2018 64bit A11 
|-
| &lt;!--Description--&gt;iPad Air 3rd Gen A2153, A2123, A2154, iPad Mini 5th Gen, 
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;2019 64bit A12 
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;{{unk| }}
|-
|}


RocketTool (USB Rocket Launchers - Toy missile launchers)
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;3px&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Original Launcher and StrikerII (includes laser)
| 0x1130
| 0x0202
| 
| {{yes|works }}
|-
| Dream Cheeky USB Missile Launcher or USB Cirus Cannon
| 0x1941
| 0x8021
| 
| {{no|no driver }}
|-
| Dream Cheeky USB Webcam Missile Launcher
| 0x1941
|
| 
| {{no|no driver }}
|-
| Rocket Baby
| 0x0a81
| 0x0701
| 
| {{no|no driver }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|}


DRadioTool (FM Radios - USB radio devices D-Link/Gemtek)
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;5%&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| D-Link DSB-R100 USB 
| 0x04b4
| 0x1002
| 0x0410
| {{yes|works }}
|-
| [http://www.neoseeker.com/forums/383/t257009-link-usb-dru-r100-radio/ GemTek USB FM Radio 21]
| 0x04b4
| 0x1002
| 
| {{N/A|untested }}
|-
| &lt;!--Description--&gt;
| &lt;!--Vendor ID--&gt;
| &lt;!--Product ID--&gt; 
| &lt;!--Revision--&gt;
| &lt;!--Opinion--&gt;
|}


UproarTool (Valencia MPX mp3 player and others)
{| class=&quot;wikitable sortable&quot; width=&quot;90%&quot;
! width=&quot;30%&quot; | Description 
! width=&quot;3px&quot; |Vendor ID
! width=&quot;10%&quot; |Product ID
! width=&quot;10%&quot; |Revision 
! width=&quot;50%&quot; |Opinion
|-
| Korean D Square Valencia MPX-Player
| 0x04e8
| various
| 
| {{N/A|untested }}
|-
|}


[https://www.youtube.com/watch?v=vIuT7rJgc8w with unlocked android bootloader], 

&lt;pre&gt;

Kill and restart the server a few times

 sudo adb kill-server
 sudo adb start-server 

And finally type in

sudo adb devices

adb devices                 Lists connected devices              

adb shell                   Opens a terminal shell on the device hollywood:/ $
su 
id
df -h
top
ls -la
ls sdcard
ls sdcard/Android
ls sdcard/Oculus
wm size 

cd ..
cd data/system              look inside bad Corejava folder 
cd data/system/etc/init     look 
cd data/system/app
cd /data
cd /dev/block


 adb shell 
 pm disable-user --user 0 com.oculus.nux.ota


adb shell am start -a android.intent.action.VIEW -d com.oculus.tv -e uri com.android.settings/.DevelopmentSettings com.oculus.vrshell/.MainActivity

Don't change your Oculus account password after doing the FB account bypass. You'll break the log-in session, and have to factory-reset and start over 

adb shell 'setprop debug.oculus.cpuLevel 5 &amp;&amp; setprop debug.oculus.gpuLevel 5 &amp;&amp; setprop debug.oculus.adaclocks.force 0 &amp;&amp; setprop debug.oculus.phaseSync 1 &amp;&amp; settings put global always_finish_activities 1 &amp;&amp; settings put global wifi_scan_throttle_enabled 1 &amp;&amp; settings put global window_animation_scale 0.25 &amp;&amp; settings put global transition_animation_scale 0.25 &amp;&amp; settings put global animator_duration_scale 0.25 &amp;&amp; sync'


 settings list --user 0 secure or global or system 
   user_setup_complete=0

 adb shell 
 screenrecord

 adb shell reboot


 adb install &lt;path_to_apk&gt;   Installs an app like adb install -g -r alvr_client_android.apk or adb install -r app.apk 

 memtester 

 lsmod 

 
adb command to enable hand tracking, possible, but root access is required 
 adb root
 oculussetting --set hand_tracking_opt_in 1 hand_tracking_enabled 1 

adb push &lt;local&gt; &lt;remote&gt;   Copies files to the device
adb pull &lt;remote&gt; &lt;local&gt;   Copies files from the device 

pull them using CFB, extract original apk using LL 

adb forward tcp:9943 tcp:9943 (Used for advanced, such as ALVR streaming)

 adb shell pm disable-user --user 0 com.oculus.partnercustomization  Enterprise versions 

adb reboot                       Performs a standard system restart
adb reboot bootloader            Restarts the device into fastboot/bootloader mode
adb reboot recovery              Restarts the device into recovery mode
adb reboot download              Reboots Samsung devices into Download Mode
adb reboot fastboot              Directly enters fastboot mode

[https://gist.github.com/pantasio/3d0eb4bb03a1e696aae8696f60730859#file-enable-usb-debug-adb usb dev debug adb]

&lt;/pre&gt;


{{BookCat}}</text>
      <sha1>51psucdq02yjpkpgluut1c7k0c02jrj</sha1>
    </revision>
  </page>
  <page>
    <title>OpenSCAD User Manual/2D Primitives</title>
    <ns>0</ns>
    <id>218798</id>
    <revision>
      <id>4657122</id>
      <parentid>4626581</parentid>
      <timestamp>2026-08-11T01:26:21Z</timestamp>
      <contributor>
        <username>Mimarx</username>
        <id>672300</id>
      </contributor>
      <minor />
      <comment>/* Extruding a 3D shape from a polygon */ center causes nowrap, so image does not stuff the code comment layout</comment>
      <origin>4657122</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="11276" sha1="eif10kfj6qu7149aypf67fg4jhrxkzp" xml:space="preserve">
All 2D primitives can be transformed with 3D transformations. They are usually used as part of a 3D extrusion. Although they are infinitely thin, they are rendered with a 1-unit thickness.

'''Note''': Trying to subtract with &lt;code&gt;difference()&lt;/code&gt; from 3D object will lead to unexpected results in final rendering.

=== square ===
----

Creates a square or rectangle in the first quadrant. When &lt;code&gt;center&lt;/code&gt; is true the square is centered on the origin. Argument names are optional if given in the order shown here.
 square(size = [x, y], center = true/false);
 square(size =  x    , center = true/false);

:''' parameters''':

:: '''size''' 
::: single value, square with both sides this length
::: 2 value array [x,y], rectangle with dimensions x and y 
::  '''center'''
::: '''false''' (default), 1st (positive) quadrant, one corner at (0,0)
::: '''true''', square is centered at (0,0)

 default values:  square();   yields:  square(size = [1, 1], center = false);
:''' examples''':

[[File:OpenScad Square 10 x 10.jpg|150px|10x10 square]]

 equivalent scripts for this example
  square(size = 10);
  square(10);
  square([10,10]);
  .
  square(10,false);
  square([10,10],false);
  square([10,10],center=false);
  square(size = [10, 10], center = false);
  square(center = false,size = [10, 10] );

[[File:OpenScad Square 20x10.jpg|150px|OpenScad square 20x10]]

 equivalent scripts for this example
  square([20,10],true);
  a=[20,10];square(a,true);

=== circle ===
----

Creates a circle at the origin. All parameters, except r, '''must''' be named.
 circle(r=radius | d=diameter);
:'''Parameters'''
:: '''r''' : circle radius. r name is the only one optional with circle.
:::circle resolution is based on size, using $fa or $fs.

:::For a small, high resolution circle you can make a large circle, then scale it down, or you could set $fn or other special variables. Note: These examples exceed the resolution of a 3d printer as well as of the display screen. 

 scale([1/100, 1/100, 1/100]) circle(200); // create a high resolution circle with a radius of 2.
 circle(2, $fn=50);                        // Another way.

:: '''d'''   : circle diameter (only available in versions later than 2014.03).
:: '''$fa''' : minimum angle (in degrees) of each fragment.
:: '''$fs''' : minimum circumferential length of each fragment.
:: '''$fn''' : '''fixed''' number of fragments in 360 degrees. Values of 3 or more override $fa and $fs.
:::If they are used, $fa, $fs and $fn must be named parameters. [[OpenSCAD_User_Manual/Other_Language_Features|click here for more details,]].

 defaults:  circle(); yields:  circle($fn = 0, $fa = 12, $fs = 2, r = 1);

[[File:OpenSCAD Circle 10.jpg|circle for user manual description]]

Equivalent scripts for this example
  circle(10);
  circle(r=10);
  circle(d=20);
  circle(d=2+9*2);

==== Ellipses ====
----

An ellipse can be created from a circle by using either &lt;code&gt;scale()&lt;/code&gt; or &lt;code&gt;resize()&lt;/code&gt; to make the x and y dimensions unequal.
See [[OpenSCAD User Manual/Transformations]]

[[File:OpenScad Ellipse from circle.jpg|Ellipse from circle]]
[[File:OpenScad Ellipse from circle top view.jpg|Ellipse from circle top view]]
 equivalent scripts for this example
  resize([30,10])circle(d=20);
  scale([1.5,.5])circle(d=20);

==== Regular Polygons ====
----
A regular polygon of 3 or more sides can be created by using &lt;code&gt;circle()&lt;/code&gt; with $fn set to the number of sides. The following two pieces of code are equivalent.

  circle(r=1, $fn=4);

  module regular_polygon(order = 4, r=1){
      angles=[ for (i = [0:order-1]) i*(360/order) ];
      coords=[ for (th=angles) [r*cos(th), r*sin(th)] ];
      polygon(coords);
  }
  regular_polygon();

These result in the following shapes, where the polygon is inscribed within the circle with all sides (and angles) equal. One corner points to the positive x direction. For irregular shapes see the polygon primitive below.

[[File:OpenSCAD regular polygon using circle.jpg|300px]]

 script for these examples
  translate([-42,  0]){circle(20,$fn=3);%circle(20,$fn=90);}
  translate([  0,  0]) circle(20,$fn=4);
  translate([ 42,  0]) circle(20,$fn=5);
  translate([-42,-42]) circle(20,$fn=6);
  translate([  0,-42]) circle(20,$fn=8);
  translate([ 42,-42]) circle(20,$fn=12);
  
  color(&quot;black&quot;){
      translate([-42,  0,1])text(&quot;3&quot;,7,,center);
      translate([  0,  0,1])text(&quot;4&quot;,7,,center);
      translate([ 42,  0,1])text(&quot;5&quot;,7,,center);
      translate([-42,-42,1])text(&quot;6&quot;,7,,center);
      translate([  0,-42,1])text(&quot;8&quot;,7,,center);
      translate([ 42,-42,1])text(&quot;12&quot;,7,,center);
  }

=== polygon ===
----
Creates a multiple sided shape from a list of x,y coordinates. A polygon is the most powerful 2D object. It can create anything that circle and squares can, as well as much more. This includes irregular shapes with both concave and convex edges. In addition it can place holes within that shape.
 polygon(points = [ [x, y], ... ], paths = [ [p1, p2, p3..], ...], convexity = N);

;Parameters

: '''points'''
:: The list of x,y points of the polygon. : A vector of 2 element vectors.
:: Note: points are indexed from 0 to n-1.
: '''paths'''
:: default
:::If no path is specified, all points are used in the order listed.
:: single vector
:::The order to traverse the points. Uses indices from 0 to n-1. May be in a different order and use all or part, of the points listed.
:: multiple vectors
::: Creates primary and secondary shapes. Secondary shapes are subtracted from the primary shape (like &lt;code&gt;difference()&lt;/code&gt;). Secondary shapes may be wholly or partially within the primary shape.

:: A closed shape is created by returning from the last point specified to the first.

: '''convexity'''
:: Integer number of &quot;inward&quot; curves, ie. expected path crossings of an arbitrary line through the polygon. See below.

 defaults:   polygon();  yields:  polygon(points = undef, paths = undef, convexity = 1);

==== Without holes ====

[[File:OpenSCAD Polygon Example Rhomboid.jpg]]
 equivalent scripts for this example
  polygon(points=[[0,0],[100,0],[130,50],[30,50]]);
  polygon([[0,0],[100,0],[130,50],[30,50]], paths=&lt;nowiki&gt;[[0,1,2,3]]&lt;/nowiki&gt;);
  polygon([[0,0],[100,0],[130,50],[30,50]],&lt;nowiki&gt;[[3,2,1,0]]&lt;/nowiki&gt;);
  polygon([[0,0],[100,0],[130,50],[30,50]],&lt;nowiki&gt;[[1,0,3,2]]&lt;/nowiki&gt;);
     
  a=[[0,0],[100,0],[130,50],[30,50]];
  b=&lt;nowiki&gt;[[3,0,1,2]]&lt;/nowiki&gt;;
  polygon(a);
  polygon(a,b);
  polygon(a,&lt;nowiki&gt;[[2,3,0,1,2]]&lt;/nowiki&gt;);

==== One hole ====

[[image:openscad-polygon-example1.png]]
&lt;!-- [[image:openscad-polygon-example1.png|frame|none|polygon with hole]] --&gt;
 equivalent scripts for this example
  polygon(points=[[0,0],[100,0],[0,100],[10,10],[80,10],[10,80]], paths=[[0,1,2],[3,4,5]],convexity=10);
 
  triangle_points =[[0,0],[100,0],[0,100],[10,10],[80,10],[10,80]];
  triangle_paths =[[0,1,2],[3,4,5]];
  polygon(triangle_points,triangle_paths,10);

The 1st path vector, [0,1,2], selects the points, [0,0],[100,0],[0,100], for the primary shape.
The 2nd path vector, [3,4,5], selects the points, [10,10],[80,10],[10,80], for the secondary shape.
The secondary shape is subtracted from the primary ( think &lt;code&gt;[[OpenSCAD User Manual/CSG_Modelling#difference|difference()]]&lt;/code&gt; ).
Since the secondary is wholly within the primary, it leaves a shape with a hole.

==== Multi hole ====

{{requires|2015.03}} (for use of &lt;code&gt;concat()&lt;/code&gt;)

[[File:OpenSCAD romboid with holes.jpg]]


       //example polygon with multiple holes
 a0 = [[0,0],[100,0],[130,50],[30,50]];     // main
 b0 = [1,0,3,2];
 a1 = [[20,20],[40,20],[30,30]];            // hole 1
 b1 = [4,5,6];
 a2 = [[50,20],[60,20],[40,30]];            // hole 2
 b2 = [7,8,9];
 a3 = [[65,10],[80,10],[80,40],[65,40]];    // hole 3
 b3 = [10,11,12,13];
 a4 = [[98,10],[115,40],[85,40],[85,10]];   // hole 4
 b4 = [14,15,16,17];
 a  = concat (a0,a1,a2,a3,a4);
 b  = [b0,b1,b2,b3,b4];
 polygon(a,b);
       //alternate 
 polygon(a,[b0,b1,b2,b3,b4]);

==== Extruding a 3D shape from a polygon ====

[[File:Example_openscad_3dshape.png|thumb|center|upright=2.0]]

    translate([0,-20,10]) {
        rotate([90,180,90]) {
            linear_extrude(50) {
                polygon(
                    points = [
                       //x,y
                        /*
                                   O  .
                        */
                        [-2.8,0],
                        /*
                                 O__X  .
                        */
                        [-7.8,0],
                        /*
                               O
                                \
                                 X__X  .
                        */
                        [-15.3633,10.30],
                        /*
                               X_______._____O
                                \         
                                 X__X  .
                        */
                        [15.3633,10.30],
                        /*
                               X_______._______X
                                \             /
                                 X__X  .     O
                        */
                        [7.8,0],
                        /*
                               X_______._______X
                                \             /
                                 X__X  .  O__X
                        */
                        [2.8,0],
                        /*
                            X__________.__________X
                             \                   /
                              \              O  /
                               \            /  /
                                \          /  /
                                 X__X  .  X__X
                        */
                        [5.48858,5.3],
                        /*
                            X__________.__________X
                             \                   /
                              \   O__________X  /
                               \            /  /
                                \          /  /
                                 X__X  .  X__X
                        */
                        [-5.48858,5.3],
                                    ]
                                );
                            }
        }
    }

==== convexity ====

The convexity parameter specifies the maximum number of front sides (back sides) a ray intersecting the object might penetrate.
This parameter is needed only for correct display of the object in OpenCSG preview mode and has no effect on the polyhedron rendering.

[[Image:Openscad_convexity.jpg|400px|]]

This image shows a 2D shape with a convexity of 2, as the ray indicated in red crosses the 2D shapes outside⇒inside (or inside⇒outside) a maximum of 2 times. The convexity of a 3D shape would be determined in a similar way. Setting it to 10 should work fine for most cases.

=== import_dxf ===
----
{{OpenSCAD_User_Manual/Deprecated|import_dxf()|[https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language#import import()]}}

Read a DXF file and create a 2D shape.

'''Example'''
 linear_extrude(height = 5, center = true, convexity = 10)
 		import_dxf(file = &quot;example009.dxf&quot;, layer = &quot;plate&quot;);

{{BookCat}}</text>
      <sha1>eif10kfj6qu7149aypf67fg4jhrxkzp</sha1>
    </revision>
  </page>
  <page>
    <title>History of Western Theatre: 17th Century to Now/French Post-WWII</title>
    <ns>0</ns>
    <id>241489</id>
    <revision>
      <id>4657102</id>
      <parentid>4637550</parentid>
      <timestamp>2026-08-10T20:26:17Z</timestamp>
      <contributor>
        <username>Neojacob</username>
        <id>363908</id>
      </contributor>
      <comment>/* &quot;The invasion&quot; */ prose improved</comment>
      <origin>4657102</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="173210" sha1="eaifr1chm366zmxydfryhbhnfqj2x1t" xml:space="preserve">=Jean-Paul Sartre=

[[File:Jean Paul Sartre 1967 (crop).jpg|thumb|Jean-Paul Sartre described conflicts arising between a German father and son and between brother and sister in the aftermath of the Nazi period]]

Jean-Paul Sartre followed up work from the previous period with &quot;Les séquestrés d'Altona&quot; (The condemned of Altona, more precisely Sequestered in Altona, 1959).

Sequestered in Altona &quot;examines guilt: to determine where it begins, where it pertains, where (and if) it ends...This drama attempts to reconcile the life of conscience, of moral passion, with the simple fact that if any crime is pursued to its logical source, the criminal is not alone. There is always a reason, social or psychological or historical, behind every immoral act that leads back to another reason, and then back to others, away from the criminal himself. But, Sartre asks, if this is true, how are we to judge, as we must? How are we to know what good is? How are we to make life better, more bearable? The dramatic image that Sartre has chosen for his theme is striking&quot; (Kauffmann, 2021, p 23). “Another preoccupation of Sartre’s which appears in ‘Les sequesters ‘Altona’ is the idea that the winner loses, and the loser wins. The father succeeds in seeing Franz only to discover that there can be no communication between them. Leni destroys the relationship between Johanna and Franz only to lose him altogether” (O’Connor, 1975 p 31). 

“In the von Gerlach household...time has stopped, because of Franz...He never had to take the responsibility for decisive acts till one day at Smolensk when he tortured a partisan. He did so allegedly for his country’s sake but really to overcome a sense of impotence, affirm his independence of his father and manifest his personal power by a major act” (Jackson, 1965 p 64). “The characters are all perfectly aware that they are in bad faith and consciously choose to remain so...Bad faith consists in the substitution of a persona for personality to use...In Leni’s words...'Here, you know, we play the loser takes all’...She tries to make Franz face up to his past...She fails...[and] merely wants to act out her chosen role, she has no interest in effecting any change in the situation...Her attitude is summarized in her incestuous relationship...Leni has chosen to be...an unsuccessful rebel...[for] failure has only to be desired to be transmuted into success...Only if [Franz] maintains his self-sequestration can she use him as a weapon against her father in her nominal rebellion against all that the family stands for...The significance for Werner of Johanna’s relationship to Franz is that it is the final indignity, [which] depends less on Werner’s relationship with his wife than on the relationship of the two brothers to each other and to their father...He wants nothing better than to please his father...but he is constantly thwarted...Just as Leni and Werner choose to be failures, so does Johanna...Johanna’s wedding was the funeral of her quintessential beauty...However, she needs an audience for her martyrdom: Werner...The driving force in Gerlach’s life has been a belief in the rectitude of capitalist power...and [he] disregarded all normal objections to the nature of Nazi power...The justifiability of the capitalist way of life...is that there are no visible alternatives...[In suicide is] the possibility of choosing the manner of his own defeat...Why does Franz feel guilty about the murder and the torture?...[He] is disgusted because he was powerless to do anything else...He had conscience...but the dominant desire was for power...His plea is that the nature of the historical process is such that evil was the only possible result of human activity...He is implying his own guilt, and guilt posits freedom” (Palmer, 1988 pp 308-317). “Franz discovers not only his own unreality and impotence but experiences in an acute form the subjective state of being hammered into the ground. Only in one particular was he not a mere image of his father and that was when he used torture, so that death is the only means by which he can escape from an intolerable situation- the realisation that he tortured for nothing- and assert what little remains of his own reality” (Wardman, 1992 p 263).

&quot;Frantz sequesters himself because of his past participation in war crimes and current participation in incest...Leni's love for her brother...thrives in the close atmosphere of her brother's more literal sequestration. It is to protect this intimacy that she has refused to be her father's messenger throughout the years. Leni is, moreover, aware that her love for her brother is part of her fanatical espousal of a certain code of tribal family life. 'Incest is my way of making family bonds tighter,' she says...Werner was born to jealousy. Rejected in favor of Frantz, Werner cannot give himself to any relationship unless it be an attitude of permanent courtship which he has adopted towards his father...The question is: why does he refuse to leave? He...is rooted in own conviction of inferiority...At first glance Johanna appears to be an energetic well-balanced woman, ready to fight for her husband...She is less an accomplice than the others and more of a victim...She has already progressed towards her own individual liberation...It is this that Werner does not understand in her and by his lack of understanding, he condemns her to the fictions which she has already abandoned...Old Gerlach had sequestered all...If he did so, it was because he himself is the greatest 'sequester&quot; of all...His single ethical code was that the end justifies the means...He said of the Nazis: 'I serve them because they serve me...But they are fighting a war to find markets for us and I'm going to have trouble with them over a piece of land'...the source of Frantz's sequestration complex&quot; (Pucciani, 1961 pp 23-30) &quot;Fear was the only emotional rapport between the domineering patriarch and his children, and Johanna discovers that his incapacity of love caused the death of his wife. Rejecting his younger son emotionally and physically, the elder von Gerlach makes Werner the prime target of his sadistic humiliations. The same lack of sentiment sequesters him from the affections of his daughter&quot; (Galler, 1971 p 179). 

“The five characters exist primarily for Franz, whose sequestration has sequestered them as well...Gerlach’s collusion with the Nazis was based on the reality of Nazi power; to remain the boss was primary and to remain a boss during the war meant to collaborate with Hitler...When the play opens...Gerlach still owns the form but no longer commands it...Franz was conceived and raised to be just like his father, a boss, with his father’s pride and his father’s passions...For three years, his father has known that he was ‘the butcher of Smolensk’. Nevertheless, von Gerlach neither can nor wants to judge his son. Bound to Franz in whatever he is, von Gerlach rejects Franz’ acts but continues to love him totally. His paternal love, born of identity, makes judgment impossible. The identity of son with father is brought to its resolution when von Gerlach takes on Franz' responsibility for his crimes as butcher of Smolensk. Left with nothing, Franz allows his father to sanctify that nothingness” (McCall, 1969 pp 128-139).  “Presumably, in Franz’ semi-lucid consciousness, the inhuman crustaceans [seen on the ceiling] represent the future inhabitants of earth, successors to a mankind that is about to bungle its last chance” (Parsell, 1986d p 1651).

&quot;Frantz’ whole life has been falsified and his freedom robbed by his father’s choice to devote everything at his disposal, including his own children, to the creation of a vast capitalist empire” (Bradby, 1991 p 44). &quot;The play's conclusion, in which father and son commit suicide by driving their Porsche off the Teufelsbrücke, points to the bankruptcy of the father's complicitous behavior and the son's ultimate moral impotence. However, the audience is also implicated because it is forced to listen posthumously to Frantz's pre-recorded speech- an analepsis created by a now dead protagonist but which is directed to the audience; yet another example of reaching back into the past to clarify the present and the future. In it, Frantz declares that 'this century would have been fine if man had not been pursued by his cruel, immemorial enemy, that carnivorous species that swore to destroy him, by that vicious hairless beast called man'. The play's final moments also share elements with 'The flies' (1943) and 'No exit' (1944). In a gesture similar to Orestes, Frantz assumes responsibility for this world and 'takes the century on his shoulders' while, as in the case of 'No exit', the play does not end abruptly. There is continuity...'Leni enters his room' and thus becomes the next prisoner of the von Gerlach enterprise, which will from now on be directed by Werner with the help of his wife Johanna (Van Den Hoven, 2012 pp 69-70).

Johanna “is the least sequestered of all, the most fearful of being a prisoner; she alone sees through sham, including her own former artificial identity as a movie tar. Werner, a fine physical specimen but weak in character, seems interested chiefly in trying to win from his father, tardily, the recognition he never received, as a younger son” (Brosman, 1983 p 95).

“Sartre’s play, one of his most complex if not his best, is marked by the extraordinary intelligence and eye for the crucial issues which are to be found in everything he writes. His theme cannot be stated succinctly; moving from morals to politics, from philosophical speculation to psychic inquiry, Sartre composes a new kind of tragedy, a black fable of human responsibility“ (Gilman, 2005 p 188).

==&quot;Sequestered in Altona&quot;==

[[File:ErnstHugo sartre.jpg|thumb|Leni and Frantz have a heavy love-hate relationship, played respectively by Margit Carlqvist and Ernst-Hugo Järegård at the Gothenburg City Theatre, Sweden, 1961]]

Time: 1940s-1950s. Place: Altona borough in Hamburg, Germany. 

Text at ?

After learning he has only a few months left to live, an industrialist, von Gerlach, wishes his younger son, Werner, to take over his boat-construction business. He also requests that Werner, his wife, Johanna, and his sister, Leni, remain together in their 32-room family mansion, watching over his eldest son, Franz, who has been kept sequestered in the house for thirteen years. Werner and Leni agree to do so, but Johanna wants to move elsewhere alone, so that the father must explain why the three should remain together after his death. In 1941, he received an offer from Goebbel, Nazi minister, to sell his field and organize a concentration camp for Jews, which he accepted. During the persecution of the Jews, Franz was caught harboring a rabbi inside his father's mansion. The rabbi was killed before his face by SS officers and Gerlach forced to send his son away in the march towards Russia. Johanna suspects that her husband tipped off the SS. In 1946, American officers were invited at the mansion, where Leni was in the habit of enflaming their desires and then dashing them with insults. One day, an officer attempted to rape her. She was able to defend herself by hitting him on the head with a bottle. To protect her from being persecuted for that deed, Franz took the blame, and, thanks to a deal with an American general, was allowed to go abroad, but instead stayed home in hiding. Johanna hates that story. She does not change her mind, delivering an ultimatum to her husband: either to stay or follow her elsewhere. Over the years, Franz has refused even to see his father, only allowing Leni to enter his room. Gerlach tries to convince Johanna to speak with Franz, at least to let him know he is dying. Franz is not the humanist he first appeared from his father's anecdotes. Wearing an officer's uniform in shreds, he keeps Adolf Hitler's picture in his room and peppers it with oyster shells. Since the end of the war, he considers the entire country overrun with weeds, passing the time either drunk or engaging in an incestuous relation with his sister. Johanna obtains Leni's secret code from her husband to see Franz. She reveals to him that his father is dying and that she would prefer to see him either free or dead than living in such a manner. After learning that Johanna succeeded in seeing Franz, Gerlach asks to see him, too, but she refuses to help him, thinking it might lead to his death. Werner thinks his father's purpose is to place Franz as head of the business in his place. Eventually, Johanna changes her mind and informs Franz about his father's wish to see him, but cannot entice him back to a normal life. &quot;I will abandon at once my life of illusions....when I love you more than my lies, when you love me despite my truth,&quot; Franz declares. He specifies that his sequestration is due not by something he did, but by what he failed to do, in passively permitting a fanatic in his troup of soldiers to torture some civilians. His confession, spurred on by a Leni jealous of her rival, repulses Johanna. Neither Johanna nor Leni are able to convince Franz to leave his room. Yet at the moment when Johanna backs off from the mutual love they began to feel for each other, he accepts at last to see his father. Franz has read in the newspapers of his father's financial successes, he who has always played the game of &quot;whoever loses, wins&quot;. Gerlach is surprised to learn that Franz accepts to run the business. While reminiscing about the past, Franz reminds him of the time when they once drove a car together at great speed, both wishing to relive that experience. When they go out together, Leni becomes certain that they will die together.

= Henry de Montherlant=

[[File:Henry de Montherlant - photo Henri Manuel.jpg|thumb|Montherlant showed how a member of the order of Santiago considers abnegation the best way to counter modern tendencies]]

Henry de Montherlant (1895-1972) followed up the previous period with another noteworthy piece in the tradition of a realist rendering of history, &quot;Le maître de Santiago&quot; (The master of Santiago, 1948).

In &quot;The master of Santiago&quot;, &quot;a father refuses to take any steps to secure his daughter’s perfectly honorable marriage to a man she loves, because he rejects all compromise with life in complacently prosperous and power-minded Spain after the defeat of the Moors. His daughter, stirred by her father’s extreme honorableness, puts an end to the hoax that would have secured him riches and that would have enabled her to marry. The father is a remarkably well-drawn Don Quixote (without any ludicrous attributes, however), and his aversion to the conniving world and the enslavement of the American Indians by Spain rises to truly heroic proportions. The flame of idealism in this drama is all-consuming. One could wish only that it also had more human warmth. The knight’s almost superhuman purity of motivation is, no doubt, intended as a slap in the face of ordinary humanity- for which Montherlant had perhaps too much contempt to become a truly great dramatist&quot; (Gassner, 1954a p 724). The grand scale of the play “takes the form of a resistance, expressed in fine language, to anything vulgar, mediocre, commonplace” (Cruickshank, 1964 p 110). 

“Don Alvaro, whose mission is to convert the Indians of the new world, scorns the efforts he directs…In the end, [Mariana] is persuaded that the institution of marriage is an obstacle to grandeur and to salvation: is this not the very reason why Catholic priests are not permitted to marry and why members of contemplative orders are closest to God?” (Cismaru, 1986 pp 1353-1354). “No wealth in the new world for him, no marriage and happiness for her! It is a total refusal, urged on by a kind of sadistic romanticism for purity...The master...is not an example of a model Christian, for his egoism, cruelty, and all his actions have a dreadful inhumanity...The love of Alvaro is a love of extermination; he has a hardness which is only explained by his pride” (Lumley, 1967 pp 345-346).

“Even at his best, [Alavaro] is only half a Christian...because the Christianity he has to apply is incomplete...He feels with great force the first constituent of Christianity, its unworldliness, its scorn of earthly comforts and riches, its renunciation, but of the sense it gives of union with God he is wholly ignorant...Now the religion of Alvaro a consists almost entirely...in a consciousness of the infinite grandeur and distance of God…But the Incarnation? The tender union with Christ on the cross?...These things remain outside of Alvaro’s experience...The truly Christian character...is...Mariana, who eventually sacrifices herself in order to share his renunciation of the world“ (Hobson, 1953b pp 179-181).

“To many, Montherlant’s ‘Christian’ drama may appear to be the study of fanaticism devoid of saintly qualities, the sort of fanaticism that stops far short of godliness and is, at best, a narrow reaching beyond the self...Don Alvaro expresses a wish to isolate himself from all worldly commerce and concerns into a carefully planned isolation for the sake of contemplation, and to gain salvation...The world has become too much for him, he does not understand it, and he ceases to want to understand it...Mariana is depicted as an obstacle forever standing between her father and God. Her father has no interest in guaranteeing Marina’s happiness by permitting her marriage...The institution of family is condemned...The Order is the real family of elected spirits with common beliefs and noble concepts. It does not impose attachments...Mariana’s serious statement that she does not wish to be happy prepares the way for an eventual understanding with her father...The father uses the cape to cover both his shoulders and his daughter’s in a gesture meant to underscore their ecstasy and their oblivion- or else their madness and their surrender of life” (Johnson, 1968 pp 110-113). 

==&quot;The master of Santiago&quot;== 

[[File:Cross_Santiago.svg|thumb|The emblem of the Order of Santiago]]

Time: 1519. Place: Avila, Spain. 

Text at ?

Members of the Order of Santiago meet at the house of their master, Don Alvero. Three of its members decide to try their fortunes in the new world. To Alvaro, the present times are rotten, compared to the famous times when Spain ousted the Mores from Spain at the battle of Granada, when he &quot;contemplated God in his cloak of war&quot;. The supposed purpose of converting Indians in the new world is &quot;impurity and excrement&quot;, because the passion of lucre, instead of sending Indians to heaven, sends Spaniards to hell. When his friends leave, Alavaro rejoices in his solitude. &quot;O my soul, do you still exist?&quot; he asks himself, &quot;O my soul, at last you and me!&quot; A friend, Don Bernal, has heard about the love-match proposed between his son, Jacinto, and Alvaro's daughter, Mariana. Because of Jacinto's expensive mode of living, Bernal suggests that he enrich himself along with others in the new world, a plan the master immediately and irrevocably refuses. Alvaro is not interested in acquiring money even for his daughter's sake, whom he best loves in the world. &quot;You will not steal my poverty,&quot; he warns his friend. He harshly accuses his daughter of dishonesty in this matter, calling love &quot;monkeyshine&quot;. &quot;Is the father of a daughter a father?&quot; he asks himself rhetorically. In an attempt to help the young lovers, Bernal asks the count of Soria to mislead Alvaro into thinking the king commands Alvaro's presence as an administrator in the new world, but Mariana, unable to deceive her father, ruins the plan by admitting the deception to him. Fed up with world affairs, Alvaro heads towards St Barnaby's convent, a place where Mariana can live, too. She accepts the offer. He covers her with the white robe of the Order of Santiago, and, with the snow falling outside, father and daughter seem ready to live buried in mystical snow.

=André Gide=

[[File:Gide 1893.jpg|thumb|André Gide showed that rumors in the Vatican can mislead both the faithful and the unfaithful, 1893]]

Another play based on a religious theme but in a more critical vein is &quot;Les caves du Vatican&quot; (The Vatican cellars, 1950) by André Gide (1869-1951), a close adaptation of his 1914 novel of the same title. The story derives from a historical event in 1893 (Ireland, 1970 p 252) when “a crooked lawyer, an unfrocked nun and a scandalous priest conspired at Lyons to spread the rumor that Leon XIII had been imprisoned by Freemason cardinals who had substituted a false pope in his place, and collected money from the faithful for his release” (Painter, 1968 p 67). The following critiques concern the novel, but is equally valid for the play.

“There are two main plots...the story of Lafcadio and the story of the conspiracy...linked by the relationship of the family...[The objective of the] Vatican swindlers...is to make a fool of society” (Painter, 1968  pp 66-67). “A pope on earth should, by definition, be a repository of infallible truth, divinely guaranteed. But of course the authenticity of the pope would, in turn, require to be guaranteed: one could have confidence in the infallibility of the pope’s pronouncement only if one could be infallibly certain that one is dealing with the one infallible pope” (Ireland, 1970 p 270).

“Protos divides humanity into two types: ‘the subtle’, to whom of course Protos belongs, are those whose Protean sensibility dictates a flexible and variable response to any given situation, those who, for whatever reason, do not present the same face to all people and in all places; they are the enemies of ‘the crustaceans’, the rigid, the insulated, the men of principle to themselves in all contexts...Protos...takes in all the aristocratic and bourgeois crustaceans...is the embodiment of escape- escape from society...one's self...one’s past, of evasion in its wildest Gidian sense, and in the sense of the perpetual mobile unrest of the creative spirit...Julius...is a novelist whose failure is due to the excessive logicality of his characterization...Lafcadio [is] turbulent and voluptuous [but] has imposed upon himself an austere discipline of self-control...to the extent of inflicting...penitential and admonitory stabs with a pen-knife for the slightest lapse in self-restraint” (Thomas, 1959 pp 157-161). “Lafcadio, a youthful vagabond...is both beautiful and amoral” (Pollard, 1991 p 365). Lafcadio’s “natural elegance and superior attainments make him a misfit in the lower classes of society, while the circumstances of his birth and the modesty of his condition exclude him from the higher” (Ireland, 1970 p 262). Each of the crustaceans, Julius, Anthime, and Amadeus, “changes his thoughts and habits, uprooting himself from all his past”, but, being crustaceans, lapse back to what they were (O’Brien, 1953 p 180).

Different though partially overlapping views have been presented on Lafcadio’s motive for murder, a seemingly gratuitous act. As a bastard, Lafcadio’s “unconscious need for recognition and parental love- it is irrelevant that he is too far gone to know what to do with them if had had them- has turned to equally unconscious need for revenge. In the mediocre bourgeois image of Fleurissoire, he pushes overboard the society that had rejected him” (Painter, 1968 p 72). “In ejecting Amadeus, Lafcadio was rebelling not only against the deeply rooted, intricately ramified family and the whole regime of the hard-shelled crustaceans, but also by implication against Wagner and Parsifal and all those who have made a cult of them...Lafcadio is a temperamental gambler who loves to play with sensations and emotions” (O’Brien, 1953 pp 185-186).  He is narcistic, “eager for self-knowledge...deriving from a frantically impatient insensibility, a consuming lust for sensation of the most intense” (Thomas, 1959 p 162). “Bored and intrigued by his companion, Lafcadio allows his imagination to wander...It is precisely [the] apparent lack of motive that the interest of the proposition lies...It is about himself that he is curious” (Ireland, 1970 p 263).

==&quot;The Vatican cellars&quot;== 

[[File:Basilique Saint-Pierre Vatican dome.jpg|thumb|People are misled into believing that the pope is imprisoned in the Vatican cellars]]

Time: 1890s. Place: Italy. 

Text at ?

Anthimus, an atheist and a cripple, is angry at his wife, Veronica, for offering votive candles to the Virgin Mary meant to improve his health. To his surprise, alone in the dark, he hears the Virgin's voice and becomes cured, joyfully throwing away his crutches and converting himself to the Catholic faith. Anthimus' wealthy brother-in-law, Julius, a writer, is requested by his dying father, a count, to visit the father's bastard son, a youth named Lafcadio, whom he has never met. To obtain information on Lafcadio, Julius proposes him some work as a secretary. In his will, the father bequests to Lafcadio a large sum of money provided he promises not to bother other members of the family with his presence, so that he need not take the job offered him by Julius. On his way to Julius' house, Lafcadio saves two children from a house on fire, to the admiration of Julius' daughter, Jennifer. Lafcadio's description of his life-history to Julius is interrupted by news of the count's death. Meanwhile, Julius' other brother-in-law, Amadeus, hears a rumor that Pope Leo XIII has been abducted and kept in a dungeon at San Angelo's fortress, annexed to the Vatican, while an imposter takes his place. The rumor is false, perpetrated by Protos, a school-chum of Lafcadio, to obtain large sums of money from gullible Catholics for the purpose of freeing the pope. When Amadeus arrives in Rome, Protos, disguised as a priest, befriends him and takes him to Naples to an associate in crime, Bardoletti, pretending to be a cardinal, who requests him to change a bond of 6,000 Francs into ready cash. At the same time, Julius is also visiting Rome to request the pope a compensation for the loss of revenues suffered by Anthimus, no longer protected by freemasons he once counted on in his career. However, he is unsuccessful at this task. Amadeus reveals to him what he knows about the missing pope, but Julius finds it dificult to believe such a story. Nevertheless, he helps him retrieve the money from the bank and gives him a train ticket in his name. By coincidence, when Amadeus takes the train from Rome towards Naples, he encounters Lafcadio, neither knowing each other. Bored with his life but willing to dare fate to the utmost, Lafcadio throws him out the door to his death. He takes with him Amadeus' train ticket but not the 6,000 francs. While meeting Julius in Rome, Lafcadio is surprised to learn that the murdered man is Julius' brother-in-law. To tease his half-brother, he leaves on the table Amadeus' train ticket. On discovering this, Julius becomes extremely worried he may become the unknown murderer's next victim. Unknown to Lafcadio, his murder was observed by Protos, who proposes to his old friend that they blackmail Julius. Lafcadio refuses and discloses his crime to Julius, a conversion overheard by Jennifer. The murder makes her love the man even more. Lafcadio makes off with her, concluding: &quot;Together, we'll know how to save ourselves.&quot;

=Jacques Audiberti=

[[File:JacquesAudiberti-1939-Harcourt.jpg|thumb|Audiberti depicted the troubles of lovers in a surrealist kingdom, 1939]]

A bridge links Jarry's &quot;Ubu the king&quot; (1888) with Dadaist and Surrealist movements of the 1920s and the Theatre of the Absurd of the 1950s. An example of a Dadaist play is Tristan Tzara's &quot;The gas heart&quot; (1921) where nonsense prevails. Examples of Surrealist plays include &quot;Victor, or the children come to power&quot; (1928) and &quot;The mysteries of love&quot; (1927) by Roger Vitrac. The playwrights of both movements seek to overthrow middle class conventions with dream images. Surrealists show interest in replacing dominant conventions with a new society, including a communist one, whereas Dadaists show little desire to replace them with anything. A bridge also bonds existential drama and the Theatre of the Absurd in Jacques Audiberti's (1899-1965) &quot;Le mal court&quot; (Evil runs, 1947), also showing affinity in the past, including Georg Büchner's &quot;Leonce and Lena&quot; (1836) and Alfred de Musset's &quot;Fantasio&quot; (1834).

In Evil Runs, &quot;the plot and the themes are deliberately conventional, bathed in the glow of fairy tale magic. The characters mostly bear functional names...and are devoid of psychological substance. They tend to talk in abstract terms...but their make-believe world is never troubled by doubts or questions from outside” (Bradby, 1991 p 188). &quot;The plot is unimportant in itself, serving only to illustrate the theme, which is that of the omnipresence and inexorable force of evil. Audiberti uses a conventional fairy-tale plot: beautiful young princess, daughter of an impoverished king, goes to marry rich young king; wicked cardinal intervenes and prevents marriage for political reasons; beautiful young princess heartbroken, etc...Audiberti carries his classic fairy-tale formula only up to a point: the rich young king does not throw the wicked cardinal into an oubliette so that he can marry the beautiful young princess at the end. Instead, the princess, Alarica, finds as the play proceeds that she is and always has been ringed around with evil and deceit. Her illusions about the goodness of life and the decency and trustworthiness of people drop from her one by one in a series of painful shocks. She discovers that her projected marriage has been secretly abandoned a long time ago and that she is being used as a decoy so that the young king can make a politically more advantageous match. Even her old and faithful nurse is in the plot. There is absolutely nobody she can trust. Everyone is self-seeking, corruptible, and dishonest because everyone is living and ordering his life within the context of an artificial and corrupt society. As the series of shocks which she is obliged to undergo bludgeon her into an awareness of the true nature of the world, Alarica realizes that she must make her compromise with it if she is to survive as something other than a pawn. She determines to fight evil with evil- to let 'the evil run'. She deposes her amiable, bumbling old father, disregarding his pleas for filial respect, and resolves to rule with complete ruthlessness. If everything is evil, then the most evil wins&quot; (Wellwarth, 1962 p 336).

==&quot;Evil runs&quot;==

[[File:Jacques Audiberti, Iz zla se zlo rodi, Slovensko ljudsko gledališče Celje.jpg|thumb|Played by Minu Kjuder (1942-?), a harassed Alarica decides to follow her lover, a king revolting to marry the Spanish king's daughter. Czechoslovakian production, 1968]]

Time: 1940s. Place: Fictional country of Shortland.

Text at ?

Alarica, princess of Shortland, must marry for political reasons Perfect, king of Occident. She hears a knock at the door and a voice stating that the king has arrived. While the princess and the supposed king confer, her lieutenant discovers that the man is an imposter. As the intruder, Ferdinand, tries to leave, the lieutenant shoots him but lets him live. While Alarica and her governess discuss the case, a second knock is heard, stating once again that the king has arrived. This time it is the genuine king, who finds the princess attractive, but the cardinal in his company reveals that their marriage prospects have been annulled, as it is more in their country's interest for the king to marry the Spanish king's daughter. &quot;We will marry Spain and make her pregnant,&quot; the cardinal affirms. However, during his absence, the king proposes marriage to Alarica and is accepted. They set off for Occident, but when the subject of what to do with Ferdinand arises, Alarica proposes that he share their bed. The king is stunned at this suggestion and no longer knows what will become of him. Although Alarica and Ferdinand sleep in the same bed, they find it difficult to agree. &quot;All that you deserve is for me to let you wade among your ideas like a comb in soup,&quot; he says. Meanwhile, the king of Shortland, Celestincinc, demands to know what a stranger is doing in his daughter's bedroom. She behaves more and more strangely to the point that Celestincin suspects his daughter has gone mad. &quot;Evil runs. A ferret! A ferret! At all costs let it run,&quot; she says. Celestincinc orders Ferdinand's arrest. Alarica disapproves of this decision. Her life has only served so far to &quot;mask the present tornado of my ferocity,&quot; she says. Inspired by Alarica, Ferdinand proposes great improvements in the land of Shortland, to the astonishment of the marshal, who finds his plans &quot;totally prodigious&quot;. Alarica proposes that the lieutenant and the marshal abandon fidelity towards her father and submit themselves entirely to her and her husband as queen and king of Shortland. They agree. &quot;Evil runs,&quot; Alaracia happily concludes.

=Arthur Adamov=

[[File:Arthur Adamov (1908-1970).jpg|thumb|Arthur Adamov described the turmoils of a writer trying to interpret the writings of a dead friend]]

Arthur Adamov (1908-1970) is another Surrealist playwright with a claim to fame, especially in presenting the problems of a writer in &quot;L'invasion&quot; (The invasion, 1950).

“At the very least we can say that Pierre's life, and to a lesser extent the lives of the others, is invaded by the indecipherable legacy of Jean. There is a real question, however, as to whether Jean even knew what he was writing. Thus it seems to me that we are entirely justified in seeing the manuscript as a symbol of the undiscernable meaning which invades life at its core...Pierre thus becomes a type of the modern man who is caught in the task of trying to discover the meaning of life, which remains obscure, and who is at the same time unable to leave off the struggle. Pierre's strategy is to forsake all communal efforts and pursue a kind of ascetic way alone. His personal quest thus takes on much of the character of the religious quest which is pursued in hermitic isolation. He refuses to speak to anyone while he is alone in his room apart. His mother brings his food on a tray but does not converse with him...Agnes' presence always represents possibilities for renewal. In the first scenes she is the one who works at the typewriter, an instrument of communication. The room is messy when she is around but the feeling is one of creative possibilities within the mess. However, as Pierre increasingly withdraws from his relationship with Agnes, these possibilities are reduced. Agnes' sexual significance is then transferred to the first man who comes along when Pierre retires into isolation, and Agnes leaves with her new man. We learn when she comes back for the typewriter that the first man who comes along has taken sick, and she is left with trying to hold his business together. Thus, perhaps, disintegration as well as renewal are symbolized in her, but so far as her relationship to Pierre is concerned renewal remains a possibility. Such a possibility is underlined when Pierre comments to his mother at the end that if only Agnes had had more patience, the two of them could have made a new beginning on the manuscript, an April renewal if you will. But this possibility had been finally frustrated by the mother, and Pierre's doom is sealed&quot; (Sherrell, 1965 pp 401-403).

“Pierre, Agnès and Tradel, their friend and collaborator, are in disagreement among themselves and unable to achieve a collective resingularization that would enable them to effectively resist the invasion of the mother and her accomplices...The mother is an invader. She takes up residence in her son’s apartment and gradually imposes her own standards of order upon it...The room is neatly ordered and immigration has been stopped. As the scene progresses, Pierre disappears to his room and dies alone. Whether he commits suicide or not is unclear, but by encouraging Agnès’s exit and then blocking her return, The mother certainly contributes to his death...Pierre, Agnès and Tradel are unable to connect and devise a strategy to resist the conservative forces because they do not appear to realize their shared interests. The audience can see the power grab of the mother, but it is not visible to those who will suffer most from it” (Chamberlain, 2015 pp 154-155).

“The dead man’s papers represent for Pierre both an occupation and a search for meaning, despite ironic suggestions throughout the play that there may well be less to Jean’s legacy than meets the eye…Agnès herself appears to stand for disorder; it is, after all, through her that Pierre has become involved with her brother and his papers...The Invasion casts serious doubt upon the validity of work, as well as that of love and friendship; such, Adamov seems to be saying, is the eventual result of all human endeavor: futility” (Parsell, 1986a p 15).

“The Invasion stresses the relative nature of truth in a world wherein absolute truth is impossible to attain. The title refers to an unfinished manuscript which intrudes into the life of the family and friends of its deceased author. The laborious struggle of these people to decipher the handwriting and clarify the work ends in a dismal stalemate for, in addition to disagreeing among themselves, they individually find different interpretations for each word until no one is certain of the real meaning” (Bishop, 1997 p 56). 

&quot;There is wide disagreement about the transcription and meaning of certain key passages. Pierre’s struggle to put his friends work in order fails; he loses his wife, his friends and even his own sense of identity in the process...Pierre’s crisis occurs when he can no longer feel the living force of language...When he says that language has lost the quality of spatial existence, he is saying that thought is no longer possible and hence that his very existence is in jeopardy” (Bradby, 1991 pp 83-84).

In The Invasion, “a play about an author who disappeared under mysterious circumstances evoking deportation, anti-refugee sentiment is explored and interrogated: the mother complains about the failure of the authorities to prevent refugees from coming to seek work and the play’s ending coincides with her wishes being met” (Morin, 2025, p 115). 

==&quot;The invasion&quot;==

[[File:Hand-writing-exam-classroom.jpg|thumb|Peter attempts to decipher a text left by his brother-in-law, but his efforts are interrupted by the invasion of his family]]

Time: 1950s. Place: France.

Text at ?

Peter works hard in trying to decipher writings left by the dead brother of his wife, Agnes. While he slowly makes way in assembling the texts, she types them up. They are helped by a friend, Tradel, but the two men do not agree on the best method of proceeding. Peter believes in obtaining the most accurate word-for-word version, while Tradel believes in obtaining an approximate version completed by their instinctive knowledge of what was meant. Because of this disagreement, Peter works alone, though Tradel warns that they must hurry, because the dead friend's family is seeking legal means of obtaining the documents for their own use. Peter thinks they can do nothing about that. An unknown man shows up to buy the apartment next door. The stranger takes pity on sad-looking Agnes, almost totally ignored by her preoccupied husband. Unable to pursue his work, Peter decides to quit for awhile and live inside a secluded room in their apartment, to be bothered by no one. &quot;I will not have peace so long as things do not show a certain perspective,&quot; he affirms. Agnes and Tradel consider this a bad idea. Peter's mother will bring him meals as usual, but he warns her never to utter a word to him. With Peter ensconced in the little room, the stranger loses no time in declaring his love to Agnes. They go off together, to the amusement of Peter's mother, who laughs and slaps her thigh at this event. When emerging from the room, Peter is ready to assume an ordinary life. He tears the papers he spent so much time on and then learns his wife has left him. He expresses understanding of her decision in view of their disordered life together, but his mother blames her for the disorder. As Peter leaves the room, Tradel returns to reveal that Agnes' family is ready to remove the papers from off their hands, but then discovers all of them torn up. Unexpectedly, Agnes comes back, but only temporarily, since her friend is sick. After brief exchanges, the mother pushes her out. When Tradel looks for Peter, he discovers him dead. &quot;I will never forgive myself,&quot; he declares. The mother looks stunned and unable to move.

=Jean Genet=

[[File:JeanGenet-HansKoechler1983-cropped.jpg|thumb|Jean Genet wrote plays which realistically and ritualistically depict the ordeals of the downtrodden, 1983]]

Another main dramatist of this period is Jean Genet (1910-1986) with &quot;Les bonnes&quot; (The maids, 1947) and &quot;Les nègres&quot; (The blacks, 1958). 

“The opening of The Maids is one of the most brilliant scenes of the contemporary theater. Dispensing entirely with exposition, it plunges us straight into the heart of what we will eventually understand to be a ritual enacted regularly by two servant sisters. Initially disconcerted by the bizarre behavior of a mistress and her maid, the spectator discovers the stylized game of domination that links them…The sisters’ daily excursion into structured fantasy is their way of surviving their stifling reality. Their staged revolt against ‘madame’ relieves them of the necessity of revolting against the real ‘madame’...The fact that the real ‘madame’, when we see her midway in the play, is clearly not the tyrant the ritual makes her out to be changes nothing in the maids’ perception. Their need to revolt is real, but their desire to revolt is undermined by their fascination of ‘madame’. Thus, they content themselves with a mock revolt, aimed as much at one another as at ‘madame’, a stylized enactment of revolt deliberately circumscribed to end just short of murder” (Bishop, 1997 pp 125-127). From the start of &quot;The maids&quot;, Solange plays her mistress' role as “domineering and insulting...The response of the maids to madame is ambivalent, a compound of hate and affection, of envy and admiration, with hate and envy predominating...The dramatic conflict in ‘The maids’ is between the condition, status, or role of servantdom and that of madamedom“ (Jacobsen and Mueller, 1976 pp 138-143). &quot;The two maids are linked by the love-hatred of being each other's mirror images...At the same time, in the role of the lady, Claire sees the whole race of servants as the distorting mirror of the upper class. Thus what they hate seeing reflected in each other is the distorted reflection of the world of the secure masters, which they adore, ape, and loathe&quot; (Esslin, 1974 p 174). “The dramatic dialogue at first appears strangely directionless– they just seem to be talking about themselves, their situation and how they want to change it– but the audience gradually begins to understand the dramatic drive underlying their discussions: they are trying to talk themselves into a state of transformation where they can escape their constricted existence and become what they are not: free agents. For in Genet’s theatre, the function of representation is not to show the world as it is, but rather to show the exaggerations and distortions through which our imaginations try to construct the desired image of ourselves and the forces that shape those imaginary selves...The maids’ repeated protestations of devotion to madame can be seen to be the product of their desperate longing to share the existence that is hers, rather than the expression of simple human affection. They are painfully aware of how Madame patronizes them and treats them just as it suits her changes of mood, with no consideration for their feelings, but they still see that her existence is deeply desirable, relative to theirs” (Bradby and Finburgh, 2012 pp 35-36). &quot;Because they hate their place so much, they also hate each other and themselves. As Solange says, ‘grime does not like grime’. The servants fail in their quest because of this hatred. As Malraux and Sartre mentioned, 'revolutions are possible only when the victims of oppression can look upon their present condition as a possible source of future dignity'...Solange and Claire have no alternative value to offer...They would like to possess madame’s qualities themselves, and although their fury at being unable to do so may express itself in dreams of murder, they finally only punish themselves” (Thody, 1968 pp 165-167). “When madame arrives, she is not the ogre we have been expecting, but a fairly ordinary, rich, over-romantic, superficial woman of the world...Claire now realizes that their first move against madame must be to kill in themselves the elements of madame they so hate- her hypocritical superiority and her self-importance...Solange’s final speech is, for the first time, honest and calm” (Gascoigne, 1970 p 191). Henning (1980) argued that &quot;when Madame returns, the cycle is apparently completed after all. But this, too, remains merely an image. The employer herself is not the genuine Bourgeois Mistress she first seems, nor really a Faithful-Woman-Suffering-for-the-Man-She-Loves. She, too, is only playing a role. Her actions even appear derisory copies of the maids' opening ritual gestures. She is herself but another surrogate monarch...Claire does assume the behavior of their mistress, but during the maids' private ceremony, it is Solange, not Madame, who plays the servant's part. The ritual reversal of roles is thus only partially achieved, and the servants can only degrade themselves&quot; (pp 80-81). &quot;The maids, wearing alternately their uniforms and their mistress' clothes, have a dual identity in several respects: humiliated drudges and triumphant vindicators, prisoners and imaginary voyagers, creators of beauty and slaves to the kitchen range, to which they add still another form of duality, that of the child and grown-up...When Claire puts on her mistress' dress, it has to be pinned up considerably for she is far too little to fit in adult attire. That Claire and Solange may not be fullgrown is further suggested by the fact that they sleep in folding cots. Although they dedicate their lives to revenge, they recite prayers in their room in the manner of pious children. They adorn their attic with fetiches, including Madame's bouquet, a behavior which is indicative of the child's refusal to part with any possession&quot; (Hubert, 1969 pp 204-205). “The maids emulate madame because they desperately desire to be integrated into the aristocratic echelon of society...Claire and Solange have no identity of their own except in relationship to madame; therefore, they want to possess the only person who defines their existence...Madame is beautiful, kind, wealthy, and a magnet for men; the maids are ugly, vicious, indigent, and have no male acquaintanceships. Frustrated by their inability to alter their social or economic status, Claire and Solange envy and thus despise madame whose patronizing attitude toward her servants only exacerbates their desire for vengeance. The maids resent being subservient, feel unable to speak honestly to their ‘patronne’ and are increasingly sexually repressed around madame, whose essence is defined by her sexual prowess. Claire and Solange engage in a ritualistic rite designed to destroy the spirit of ‘madameness’ so that the outcasts...can transcend their inferior statuses in defiance of the established ruling class” (Plunka, 1992 pp 176-177). &quot;Madame is, of course, a kept woman and as such bears a curious relationship to the maids themselves. She is actually a member of another sub-world, a higher sub-world than that of the maids, to be sure, but a sub-world nonetheless. And so she too, to a certain extent, lives by fantasy and imagination. We see this at once in the way she dramatizes the arrest of Monsieur. She is not really herself, but alienated, like the maids, in her being. And we see further that the role she plays in her relationship with Monsieur is actually the prototype for the role of the two maids. She recounts now the story of his arrest, the anonymous letters and above all the heroic role which she plays in the whole affair. Solange tries to reassure her. She says that Monsieur is innocent and will be acquitted. 'He is, he is,' answers Madame. And yet a false note creeps in. We gather that Madame rather enjoys her role of martyr and saint. She will be faithful to Monsieur whatever happens. She will follow him from prison to prison. She will give up her elegant life, her beautiful dresses made to order by Chanel, her furs. She has a moment even of false sympathy for her two servants. They will all retire to the country together. They will be faithful to her and she will take care of them&quot; (Pucciani, 1963 p 53). “This extraordinary play, with its perfect one-act structure, its overwhelming dramatic tension, and its density of thought and symbolism, is rightly considered one of the masterpieces of the contemporary theater. It is a play about masks and doubles, about the evanescence of identity” (Coe, 1986b pp 682-683).

“The blacks” “is an ironic howl at and mockery of every thing the paleface thinks, says and, in furtive guilt and repressed aversion, fails to say against the dark-skinned peoples...It is all done with a grin which has little humor, though it will provoke a frightened laugh” (Clurman, 1966 pp 74-75). “Rejecting the ‘white’ value of universal love, the participants in the rite must struggle to discover absolute hatred. At its centre is the re-enactment of the murder of a white woman by Village. The catafalque placed centre-stage supposedly contains her corpse, and there is lengthy discussion about whether Village was attracted to her or not. This is important to Archibald, in charge of the rite, since he has to determine whether the crime was committed out of pure hatred: ‘His crime saves him.’” (Bradby and Finburgh, 2012 p 75). “The principal question...is whether Village committed the murder from the right motivation and in the right spirit. Was his deed executed in a way that would do full justice to the very soul of blackness?...Accordingly it becomes necessary for Village to re-enact the murder...Archibald reminds them of the desired goal: ‘we must deserve their reprobation and get them to deliver the judgment that will condemn us’...They must live up to the concept of blackness as defined by the whites. But [afterwards] the blacks have moved toward...the determiners of their own actions...The judge...aghast that no murder has been committed, sees the evaporation of his role...The possessed...must stop short of murder...for [that] would deprive [them] of possession”  and so the roles become reversed (Jacobsen and Mueller, 1976 pp 158-162). “In relation to each other, Village and Virtue are powerless; both are Black and their Blackness is negation, is nothing but a function of White. Its only chance of self-realization is to reverse the roles of Figure and Reflection. Only by destroying-conquering, dominating or absorbing-White, by asserting its own values against those of the conquerors, will Black become the Figure, and White be re- duced to the part of Image-in-the-Mirror” (Coe, 1968 p 292). There is a tight relation between stage events and the uprising behind the scenes. “The play performed for the audience is a deception that masks the underlying motive of the blacks onstage: a ritualistic self-immolating and subsequent exorcism of white values, producing a rite of passage to a new identity...The whites in the audience are at ease to see blacks imitating white culture...The blacks are associated with the white 19th century colonialist view of Africa as a savage primitive world...The court, played by blacks in white masks, represents white society, or at least a stereotyped black view of what white society represents...Dispossessing themselves from white authority and power, the blacks establish their own identities and begin to make their own judgments which are manifested by the offstage trial of a black traitor...Diouf, as Marie, gives birth to five dolls representing the white court...[signifying] the murder of the white race” (Plunka, 1992 pp 226-233).  “The ritual is designed to disintegrate the white image, the uprising to disintegrate the whites” (Brustein, 1964 p 408). &quot;All the whites in Genet's play are uniformed and stand for more than themselves. They are, in fact, symbols of authority. In colonial Africa native secret societies and social clubs often gave their officers the costumes and titles of queen, governor, judge, and missionary, thus both emulating the whites and challenging their monopoly of the symbols of authority&quot; (Graham-White, 1970 pp 210-211). “The court is made up of blacks wearing white masks. These masked beings secretly long to reverse the order of things and become the oppressors, the voice of authority. Yet they know very well that they belong to the black unprivileged race...The members of the white court want to assume their obligations, which indicates a certain faith in the future; however, they do not want to assume their functions as whites but as blacks” (Knapp, 1968 p 137). “The court in this play is ineffective. It is the blacks who must try one of their own. Part of the ineffectiveness of the white court is the fact that they cannot keep up a normal conversation. Their speech is marked by random outbursts that lead the trial nowhere. One reading of this can be that a white court cannot understand and make sense of a black crime...Another reading can be that...justice is impossible to the blacks” (Bennett, 2011 p 82). &quot;The destruction of the whites as they appear is seen as the only way to better their condition. The blacks fight the whites in their purpose to obtain political independence and be able to enjoy emotions other than hatred&quot; (Thody, 1979 p 199). &quot;'The blacks' begin by dancing a minuet to a Mozart melody around a catafalque which occupies center stage. Even though the element of parody is apparent in their movements, the minuet signifies the enslavement of the blacks to white culture. That enslavement is both the starting point and the ending of the play&quot; (Oxenhandler, 1975, p 422). &quot;The actors enter in two groups...but the final stage image is one of solidarity: 'all the blacks- including those who had been the court, now without their masks- stand about a coffin draped in white...The traditional values of white society are scorned, belittled, and reduced to playing 'a tune by Charles Gounod', knitting 'balaclavas for chimney-sweeps', singing 'at the harmonium' and praying on Sundays...The actors are working themselves up into a state of excitement in anticipation of the 'murder' of Diouf (disguised as a white victim), when Village halts the action. Up until this point, Village has painstakingly tried to explain his actions to the audience in repeated asides, but now the whole ceremony is going to move beyond the comprehension of the audience as narrative gives way to magic...Throughout Diouf's recitals, the court integrates itself with the players in the ceremony. They applaud and laugh at the mimed gestures as though they were real. Meanwhile, the white spectator marooned on stage, his hands tied, so to speak, by holding the knitting, can do nothing but look on...The action of the play does not aim to resolve the conflicts of the initial situation; rather, it tends to exacerbate them&quot; (Webb, 1969 pp 455-458). &quot;The Missionary...proudly states, to the tacit agreement of white believers and the bemused rejection of the black ones, that God is white, a belief used over the centuries to keep God-fearing blacks from seeking to reach too far up the ladder of equality. 'For two thousand years God has been white. He eats on a white tablecloth. He wipes his white mouth with a white napkin. He picks at white meat with a white fork.' The blacks realize that their eventual mental liberation cannot be achieved until they are able to reject and revise color symbols such as used by the whites. Thus, Felicite, toward the end of the play, states that 'everything changes. Whatever is gentle and kind and good and tender will be black. Milk will be black, sugar, rice, the sky, doves, hope, will be black'...The blacks in the play derive utmost pleasure from emphasizing precisely those ideas or views that society has held against them...From the very beginning, blacks proceed with a black-is-beautiful ritual, never missing an opportunity to emphasize their blackness and being chided if they appear not to do so. Archibald, who keeps the action moving along...advises Neige: 'You wanted to be more attractive- there's some blacking left'&quot; (Warner, 2014 pp 201-203). &quot;The whole play is a hymn of hatred: the loathing of blacks for whites deliberately played upon and gloried in...the catafalque remains throughout the play visually at the centre of the stage. It is thus precisely one of the deepest of all racist fears that Genet plays on, namely interracial sexual jealousy&quot; (Martin, 1975 pp 519-522). “However much his white audience may disapprove of what the negroes are doing, they are not seeking evil for its own sake, but for political aims that can be rationally formulated: independence, freedom, self-respect” (Thody, 1968 p 200).

Antonin Artaud prefigured Genet’s theatre in its myth-creating goals, the use of language as incantation, communicating emotions rather than exchanging ideas, and the use of visual and auditory aids in the form of “music, dance, plastic art, pantomime, mimicry, gesticulation, intonation, architecture, scenery, and lighting” (Artaud, 1938). “Genet pulls his myths from the depths of a totally liberated unconscious, where morality, inhibition, refinement, and conscience hold no sway; at the basis of his work is that dark sexual freedom which Artaud held to be the root of all great myths&quot; (Brustein, 1964 p ). &quot;All Genet’s plays present us with anti-societies. The worlds of prison, brothel, blacks or rebels are all defined by opposition to traditional, habitual, right-thinking society. The people inhabiting these worlds are all aware that their existence and, more profoundly, their very consciousness is conditioned by the contempt of others. But Genet’s plays do not therefore, like some absurdist dramas, dissolve all social distinctions in a vision of nightmarish horror. Instead, they investigate with precision the levels of interdependence that link the oppressor to the oppressed and they present ceremonies of metamorphosis in which the oppressed, by accepting and exaggerating their condition, hope to turn their shame into pride, to change the rules of the game so as to turn the tables on their oppressors“ (Bradby, 1991 p 179). 

==&quot;The maids&quot;==

[[File:Jean_Genet,_Služkinji,_SNG_v_Mariboru.jpg|thumb|Solange and Claire hate their employer but wind up destroying each other. Bogdana Bratuž (1934-?) as Solange (left) and Milena Muhič (1937-2014) as Claire (right) in a 1969 Czechoslovakian production]]

Time: 1940s. Place: France.

Text at https://web.mit.edu/jscheib/Public/phf/themaids.pdf https://pdfcoffee.com/genet-jean-the-maids-amp-deathwatch-grove-1954pdf-2-pdf-free.html

Claire commands her servant, Solange, to dress her up in all her finery.  Her constant recriminations incite Solange to fury. She strikes Claire and threatens worse until the alarm-clock rings, at which point Claire cries out: &quot;Let's hurry. Madam will come back.&quot; Claire is a servant as well and they have only been play-acting. Claire blames her sister for always being late, so that they never reach the moment of their mistress' murder. Despite frustrations inherent in their servile state, Claire is nevertheless of the opinion that at heart  their mistress loves them. &quot;Yes,&quot; Solange comments sarcastically, &quot;like the pink enamel of her latrine.&quot; To avenge themselves of their lot outside of play-acting, Claire has written an anonymous letter to the police, accusing her mistress' lover of robbery and leading to his arrest. Solange intends to go further, revealing that she was once tempted to kill their mistress as she slept, but her courage failed her when she moved. &quot;She will corrupt us with her softness,&quot; she warns. To their consternation, Claire learns from a telephone call that the man was set free on bail. Claire blames her sister all the more for failing to kill her. Now they well may be denounced as false accusers and imprisoned. &quot;I have enough of being the spider, the stem of the umbrella, the sordid and godless nun with no family,&quot; Claire says despondently. They whip up further accusations against their mistress but to no practical avail. &quot;Yet we can't kill her for so little,&quot; Solange admits. She suddenly changes her mind again, and suggests dissolving barbiturates in their mistress' lime-blossom tea. Their mistress enters, distressed about her lover's state, ready to follow him to a far-away prison. &quot;I will have newer and more beautiful dresses,&quot; she decides. She gives Claire her silk dress and Solange her fur-coat. Then she notices the telephone off the hook. Solange blurts out that her lover called. She is led on to reveal that her mistress is to meet him at a restaurant. The mistress wants to join him at once and leaves before drinking the tea meant to poison her. &quot;All the plots were useless. We are damned,&quot; Claire concludes. Solange suggests that they should escape, but Claire finds the suggestion impractical, both being poor with nowhere to go. They uselessly curse their servile state. In despair, they resume play-acting, Solange this time in the mistress' role asking for her tea. But then Claire resumes the mistress' role again to swallow the poisoned tea while Solange's hands cross themselves as if already handcuffed.

==&quot;The blacks&quot;== 

[[File:John Breck The Blacks 001.jpg|thumb|Archibald Absalon Wellington is the master of ceremonies who advises Mary before her rape and murder at the Citizens Theatre, Glasgow, Scotland, 1980s]]

Time: 1950s. Place: White-colonized Africa. 

Text at ?

A group of black people present the murder of a white woman on a stage in front of a court composed of other black people thinly disguised as whites, including a queen, a governor, a judge, a missionary, and a servant. Archibald Absalon Wellington is the master of ceremonies, guiding the spirit of the presentation towards greater hatred of white colonization. Before a hearse, Archibald asks Village what happened that morning, who answers he strangled a white woman named Mary with his own hands. On hearing of this event, the queen grieves. &quot;Be confident, your majesty, God is white,&quot; the missionary consoles her. When some of the blacks are distracted from contributing to any worthwhile cause, Archibald reminds them that they must merit the court's reprobation. In their stage presentation, Mary's role is played by Diouf, a vicar,  Mary's mother's role by Felicity, a whore, and a man named Bobo her neighbor. While Mary speaks to her eventual rapist and murderer, the mother constantly cries out for her &quot;pralines and aspirin&quot; and reminds her it is time for prayers. The neighbor copmes over to remind Mary that her eyes may be ruined if she continues to work in the dark. During the course of the evening, Mary plays the piano, an art approved of by the queen: &quot;Even in adversity, in a debacle, our melodies sing out,&quot; she declares enthusiastically. Unexpectedly, Mary is about to give birth. The neighbor arrives as the midwife and takes out from beneath her smock dolls representing the five members of the court. She is then murdered and the court convenes for the condemnation of the murderer. The missionary considers that the victim should be beatified, but the queen is uncertain whether that idea is wise. &quot;After all, she was sullied, defending herself to the last, I hope, but she may remind us of her shame,&quot; the queen considers. During the court proceedings, the black people rebel and the five members of the court must escape their fury. To ease their fatigue on their way along roads and fields, the missionary approves of the use of alcoholic drinks. However, they get drunk. &quot;Dances occur only at night, none of which do not intend our deaths. Stop. It is a frightening country. Each brushwood conceals a missionary's tomb,&quot; the missionary warns them. The judge succeeds in re-organizing the court in session, whereby the members of the black population begin to tremble, but one of their leaders, Felicity, arises to challenge the queen. Another of the black leaders, Ville de Saint-Nazaire, reveals that a traitor in their midst has been executed, but that a new leader of the rebellion is found. The court-members are surrounded, yet the queen admonishes them to courage amid adversity. &quot;Show those barbarians that we are great by our attention to discipline and, to white people looking on, that we are worthy of their tears,&quot; she declares. Despite this encouragement, one by one the members of the court are executed.

=Eugène Ionesco=

[[File:Eugene Ionesco 01.jpg|thumb|Eugène Ionesco was the initiator of the Theatre of the Absurd, 1993]]

The Theatre of the Absurd originated in France in the 1940s, the first of whose main proponents is Romanian-born Eugène Ionesco (1909-1994) with &quot;La cantatrice chauve&quot; (The bald soprano, more precisely the bald primadonna, 1948) and &quot;Rhinocéros&quot; (Rhinoceros, 1959). &quot;Both Ionesco and Beckett are concerned with communicating to their audiences their sense of the absurdity of the human condition&quot; (Esslin, 1960 p 671). &quot;If a good play [in the Realist style] must have a cleverly constructed story...[Absurdist plays] have no story or plot to speak of; if a good play is judged by subtlety of characterization and motivation, these are often without recognizable characters and present the audience with almost mechanical puppets; if a good play has to have a fully explained theme, which is neatly exposed and finally solved, these often have neither a beginning nor an end; if a good play is to hold the mirror up to nature and portray the manners and mannerisms of the age in finely observed sketches, these seem often to be reflections of dreams and nightmares; if a good play relies on witty repartee and pointed dialogue, these often consist of incoherent babblings&quot; (Esslin, 1974 pp 3-4) &quot;The convention of the absurd springs from a feeling of deep disillusionment, the draining away of the sense of meaning and purpose in life, which has been characteristic of countries like France and England after the Second World War. In the United States, there has been no corresponding loss of meaning and purpose” (Esslin, 1974 p 266). Unlike Camus’ essay, “The myth of Sisyphus”, and Sartre’s novel, &quot;Nausea&quot;, both of which treating rationally of irrationality, Ionesco and other members of the Theater of the Absurd treated irrationality in an irrational manner. “An irrationalist theater is not merely a theater that attacks the idols of rationalism, indefinite progress towards happiness through science...it is, above all, a theater which is meant to be a genuine expression of the irrational” (Doubrovsky, 1973 p 12). In the 1950s to the 70s, absurdist plays or plays with absurdist elements dominated to the extent that, in the view of Fuegi (1986), “it is only the absurd drama that is not absurd” (p 204).   

The Bald Prima Donna, &quot;the picture of the human condition...is cruel and absurd (in the sense of devoid of meaning). In a world that has no purpose and ultimate reality the polite exchanges of middle-class society become the mechanical, senseless antics of brainless puppets. Individuality and character, which are related to a conception of the ultimate validity of every human soul, have lost their relevance...The audience knows no more about the mcaning of the mechanically senseless dialogue than do the characters themselves. What is involved is a savage satire (which is by no means the same as irony) on the dissolution and fossilization of the language of polite conversation and on the interchangeability of characters that have lost all individuality, even that of sex. Such characters lead a meaningless, absurd existence.... My contention is that the source of...laughter is not to be found in any irony but in the release within the audience of their own repressed feelings of frustration. By seeing the people on the stage mechanically performing the empty politeness-ritual of daily intercourse, by seeing them reduced to mechanical puppets acting in a complete void, the audience while recognizing itself in this picture can also feel superior to the characters on the stage in being able to apprehend their absurdity- and this produces the wild, liberating release of laughter- laughter based on deep inner anxiety&quot; (Esslin, 1960 pp 671-672). The play “is almost in its entirety an exaggerated depiction of the hollowness of bourgeois life through the use of caricature...What is frightening...is how closely it resembles the banal conversations that go on in middle-class homes night after night...The characters hide their boredom and their dislike for one another behind the clichés of polite speech and the routines of conventional behavior. So mechanical have their lives become that they are incapable of learning anything” (Abbott, 1989 p 159). “The dialogue is mainly in the form of self-contained statements that attempt little interlay...When the dialogue is initiated...conversation is little more than sense destruction...[When] the Martins are introduced...the dialogue...grows out of their mutual wonder over the coincidence of their parallel existence. This process is the reverse of the incongruity that fails to surprise; here it is the expected that evokes stereotyped amazement” (Grossvogel, 1962 pp 53-54). &quot;The bald primadonna&quot; presents &quot;characters...already devoid of humanity...who do not possess even a memory of propitious times, who are the same at the falling of the curtain as they were at the beginning, and who seem unconcerned with any possible release from their imprisoned circumstances- indeed...are unaware of any imprisonment...lack any tragic sense of their condition...The incredible elicits little surprise, [as when the fireman rings the doorbell], the ordinary is greeted with incredulity” [as when Mrs Martin describes a man tying his shoelace in the street]&quot; (Jacobsen and Mueller, 1976 pp 46-54). The conversations between the Smiths and Martins derive from instruction manuals to master a new language (Hayman, 1976 p 17). “The Martins...are so lost in their individual solitude that after years of married life they do not recognize each other. Their life together has been one of mechanical repetition. People are so interchangeable, so anonymous, that at the end of the play the Martins may take the roles assumed at the beginning by the Smiths” (Pronko, 1959b p 35).“The dislocation of everyday language in the play is progressive, passing through several phases. At the beginning of the play, the language is remarkable primarily for its sheer inanity...The second stage in Ionesco's assault on language encompasses most of the rest of the play; it begins when Mr Smith starts to speak and continues until the departure of the fire chief (scene 10). As soon as the monologue becomes dialogue, it is apparent that the logic governing the world of this play has nothing to do with that of the spectator's world. In this part of the play, the forms of polite conversation are left largely intact, but their content is skewed and zany” (Lane, 1994 pp 31-32). “The Smiths and the Martins...are devoid of identity. The characters mimic each other for lack of imagination, parroting contemporary clichés and boilerplate remarks because they are so eager to please they have lost any semblance of self outside the herd” (Krasner, 2012 p 308). “The Martins’ problem is that, even though they have been introduced to us as man and wife, they don’t know each other...we see a typical couple, married for some years, who do not know each other” (Wellwarth, 1971 p 62). &quot;No sooner have the chimes struck seventeen times than Mrs Smith announces that it is nine o'clock. A joke? Of course it is a joke. But it also reveals that the specific time of day is meaningless, because from hour to hour and day to day, their lives are essentially the same. It is also noteworthy that the couple is named Smith: a perfectly conventional, nondescript, middle-class name for conventional, nondescript, middle-class people...The uniformity, as well as the lack of vital life in the lives of the members of the bourgeoisie, is revealed when the Smiths discuss Bobby Watson...There is no difference in the pattern of existence between one bourgeois and another...Ionesco frequently employs a grotesque reversal of the usual. He accomplishes this by taking a familiar situation, injecting into that situation a single element which renders it completely improbable, and then writing the scene as though the improbable element were not there. Such a scene occurs when Mr and Mrs Martin enter...and Ionesco presents not only a brilliant satire on cocktail party conversation, but- and more to the point- on the bourgeois preoccupation with inconsequentials. At first, each of the characters gropes for something profound with which to impress the others. The result is a plethora of banalities...Mr Smith goes to the door and returns with the fire chief...[The explanation of the doorbell matter] satisfies all concerned, for it is the classic bourgeois manner of settling controversies: choosing the middle path between two extremes...Enter the Maid, who turns out to be the fire chief's sweetheart. Here, too, passion is extinct, for, as the fire chief declares, 'it was she who extinguished my first fires'...When the fire chief leaves, Ionesco presents another illustration of the dull routine of these people's lives. The party conversation becomes a series of clichés: 'to each his own,' 'an Englishman's home is truly his castle,' 'charity begins at home'- [which] follow each other with no logical continuity&quot;(Dukore, 1961 pp 176-177). Lane (1996) enumerated the disruptions of logical discourse include pseudo-explanations (the patient died because the operation failed), false analogies (a conscientious doctor must die with his patient like the captain of a sinking ship), contradictions (the Smiths have had dinner until the maid enters), specious reasoning (when the doorbell rings, it is because no one is there), surprise at the obvious (why newspapers never print the age of newborns), unreliability of proper names (the Watsons), aphasia (a woman is asphyxiated because she thought the gas was a comb), word-action contradiction (the fire chief says he will take off his hat but not sit whereas he does the reverse). The characters lack any discernable motivations, rationality, or internal life, rather they are like puppets...Undifferentiated from each other and indistinguishable from their surroundings, they are traversed by language which uses them rather than the other way around” (pp 32-39). 

Rhinoceros “fuses fantasy and reality, using the outrageous convention of turning characters into rhinoceroses in order to make a strong political point and comment on the nature of social oppression. Rhinoceros even goes so far as to play with the line between fiction and reality by having one of the characters ask Berenger if he’s read any of Ionesco’s plays, blurring any distinction between the representation and the real” (Saddik, 2007 p 31). “The acute paralysis of will, vacuity of imagination, bureaucratic corruption, vicious authoritarianism, self-serving interests, demonstrative self-congratulatory pandering, and primarily the need to please at all costs to one’s individuality are for Ionesco symptomatic of modern culture’s predicament. The cacophony of demands from both left and right extremists is symbolized by the barrage of noise in the thundering herd of rhinos trumpeting through the town. The rhinos epitomize an excess of power bereft of vision; for Ionesco, we live in tragic times...because our power to change circumstances has reached an aporia” (Krasner, 2012 pp 313-314). “Fatalism and indifference become common sense...What is so compelling and convincing about Ionesco’s presentation of the rhino mentality...is that it is reinforced by kinship patterns...Family feelings override what should have overridden family feelings” (Hodgson, 1992 p 135). “When the first rhinoceros upsets the decorum of the community, their comments are entertainingly inadequate...Unable to grasp the significance of the new invasion, the characters run off into irrelevancies that flatter their egos...Their minds are too static. They have no principles. Their imaginations are sluggish. They can only repeat the clichés from the normal periods of their lives. And it should be remarked that the only human being who refuses to become a rhinoceros is the one with the most commonplace mind and the least personality” (Atkinson and Hirschfeld, 1973 pp 272-273). “Berenger...is an unlikely hero: he is hungover, dishevelled and directionless. His unheroic disposition makes him an Everyman, somebody who could be, or inspire, anyone. Although average, he is exceptional. By resisting the rhinoceroses, he is the only person to preserve his singularity and, in literal terms, not to become dehumanized by conformity. Moreover, he not only prioritizes his own individuality, but also respects that of others, showing conciliation and compassion towards friends and colleagues before they metamorphose. He is thus the only character with psychological depth” (Finburgh, 2015 pp 119-120). Berenger “changes from a listless slouch to an ardent defender of an irreplacable set of human values” (Gaensbauer, 1996 p 102). “His aversion to the rhinoceroses is visceral. ‘Just the sight of them upsets me,’ he says. Inarticulate, he counters John’s defense of rhinoceroses not with argument but with feeling” (Lane, 1996 p 114). “Berenger is...weak confused, fearful, alcoholic. Yet he will not yield” (Bloom, 2005a p 248). “What the play conveys is the absurdity of defiance as much as the absurdity of conformism, thc tragedy of the individualist who cannot join the happy throng of less sensitive people” (Esslin, 1974 p 151). &quot;We find little in Berenger's life that would appear to be worth defending. Early in Act I he confesses to his friend Jean that he is bored and tired and unsuited to the office job that he nonetheless performs dutifully...The other characters in the play are no more successful than Berenger in creating, through their lives, a form of humanity that would appear worth struggling to preserve...If meaningful thought is the necessary criterion for being, the logician has a minor but memorable role as the master of the false syllogism, less alive than anyone on stage. Confidently ignoring the logical limits premises, he concludes that four-pawed creatures are necessarily cats...It is a mark of Berenger's lack of discernment that he is favorably impressed by the logician...As a final example of the intellectual atrophy with which the supposedly characters of Rhinoceros are afflicted, consider the mental activity of the schoolteacher, Botard. Like the fanatics who refused a few years ago that men had actually walked on the moon, Botard adamantly rejects...newspaper accounts of the presence of rhinoceroses...When Botard later denounces academe he is in effect rendering an accurate self-assessment: 'what University people lack are clear ideas, the sense of observation, common sense'...All that remains of human civilization in the play is an almost unintelligible human-like verbal debris, unconnected fragments of logic, hollow figures posing as human beings...Understandably, then, Berenger is in an awkward position when he works away gradually, in the famous long speech that concludes the play, into a posture of resistance, on one hand, and defense of mankind...How will he communicate with the rhinos?...Right or wrong, they are in his view attractive and he ugly in contrast...His final words are less heroic or courageous than silly in their recalcitrance...[The play's lesson might be:] individualism in defense of non-humanity is no virtue...bestiality as an alternative to unreasoning human existence is no vice&quot; (Danner, 1979 pp 210-214). &quot;Jean, who is admonishing Bérenger for his moral laxity, and the professor, who is conducting a logical argument on another part of the stage, end up saying exactly the same lines, echoing one another in perfect unison although their intended meanings are entirely different...The inarticulate roars of the rhinoceros, however, are able to communicate directly with those who are beginning to feel tempted to join them” (Bradby, 1991 p 76). Berenger is the only character who changes. “He alone is unwilling to take them for granted. His moving from apathy to engagement, and from near death to life, is charted as he debates with one character after another about the blandishments of rhinoceritis” (Jacobsen and Mueller, 1976 p 66). In contrast, Dudard considers rhinoceritis a mark of a ‘community spirit triumphing over anarchic impulses’ (Hayman, 1976 p 110). John is “intent on keeping up appearances...the most hypocritical and self-righteous...fastidious, boastful of his imagined superiority over Berenger...The first to surrender his humanity...Botard is the most arrogant, stubborn, and unreasonable...He at first categorically rejects the story of the rhinoceroses...but...shares a strong sense of duty...to adhere to whatever or whoever is in power...Dudard is a relativist. He responds calmly....urging that the best course is simply to ignore the beasts and acclimatize oneself to the changing times...Daisy...opts for the ‘natural’ life, calling the rhinoceros ‘real people’” (Jacobsen and Mueller, 1976 pp 42-46). “Botard is just as narrow-minded and pedantic as the young arriviste Dudard. Skeptical and obstinate, Botard is convinced that the plague of rhinoceritis is a right-wing conspiracy, sustained by the press, and consumed by the masses. Denying the existence of rhinoceros in the town, Botard calls it an instance of ‘your propaganda’ and an ‘infamous plot’, part of what he deems to be a capitalist ploy to make money. Botard accuses the journalists of fabrication: ‘they don't care what they invent to sell their wretched newspapers and please the bosses they serve’” (Quinney, 2007 pp 46). “The play, despite the central figure’s defiance of bestiality, is essentially anarchic, bitter, very nearly hopeless. The rational mind and logic are absurd, Ionesco tells us; they have little relation to the truth (which is the chaos) of life” (Clurman, 1966 p 86). In contrast, Bennett (2011) proposes that “much of the success of totalitarian regimes is the complacency of the masses. But rhinos have no known predators (except humans) and are probably one of the last animals one would think could be herded...Different species can display remarkably different social traits, ranging from solitary to gregarious...How does one maintain individuality within a group that needs to act as one?...Berenger takes on a Sisyphian purpose...We can make our lives meaningful through our revolt and creating a purpose by which we can live by” (pp 95-98). “The earlier heroes feel that they are working for something greater than themselves and that hope sustains them in their quest. In Ionesco’s universe, no cosmic or religious meaning is given to Berenger’s refusal to capitulate” (Abbott, 1989 pp 165-166).  “Rhinoceros thus emerges as a chilling portrayal of man in society, any society, ostracized by his fellows for reasons that he cannot fully comprehend” (Parsell, 1986c p 1002). “In drama, as in fiction, the sign of...debilitation is currently an unwillingness (arising, I suspect, from an incapacity) to create characters. A certain anti-humanism is connected with this quality, and one may sense its presence even in a work that presents a concern over the dehumanization of mankind as explicitly as Rhinoceros does” (Gassner, 1968 p 502). “The meaning of the play is clear: man is only too inclined to forget his humanity, his individuality and independence; following the pressure of the times, he becomes like everyone else. The rhinoceros are an amusing-and at the same time frightening-symbol of man giving in to his animal nature” (Pronko, 1961 p 69).

“Ionesco is a formidable parodist, a sardonic skeptic, and an almost irrepressibly gay nihilist; he is as effective in comedy as in pathos. He is capable of challenging reflection while outraging sensibility or tickling our funny bone with his clowning, and of depressing and amusing us almost in the same breath” (Gassner, 1960 p 261). &quot;When his characters experience lightness, joy, evanescence, it is always a solitary emotion. They cannot derive joy from togetherness with others. In fact, it is almost always the pressure and intrusiveness of social existence that destroys their inner sense of bliss” (Bradby, 1991 p 81).

==&quot;The bald primadonna&quot;==

[[File:Theatre_Huchette.jpg|thumb|Something strange and absurd is occurring in a house with two couples, a servant, and a fireman. Poster of the play at the Theatre de la Huchette, 2006]]

Time: 1950s. Place: London, England. 

Text at https://macaulay.cuny.edu/eportfolios/smaldone2011/course-readings/

While Mrs Smith prattles about domestic affairs, Mr Smith clicks his tongue. He reads in the newspaper a mention about Bobby Watson's death. Mrs Smith specifies that it is his wife, Bobbie Watson, that she is now thinking about. The Smiths suggest that the Watson children, Bobby and Bobbie, may be taken care of by an uncle and aunt, Bobby and Bobbie Watson, respectively, so that the widow may remarry. &quot;Has she anyone in mind?&quot; Mrs Smith asks. &quot;Yes, Bobby Watson's cousin,&quot; Mr Smith affirms. &quot;Who? Bobby Watson?&quot; his wife queries. &quot;Which Bobby Watson are you talking about?&quot; he queries back. &quot;The son of old Bobby Watson, other uncle to the dead Bobby Watson,&quot; she answers. &quot;No, not that one,&quot; he says. &quot;Bobby Watson, son to the old Bobbie Watson, Bobby Watson's aunt.&quot; After settling that matter, their invited guests arrive, a man and a woman who do not know each other. While conversing, the two guests are astonished to discover that they many things in common until realizing they are man and wife. The doorbell rings. Mrs Smith gets up to see who it is, but there is no one. The same thing happens twice more, until an angry Mr Smith gets up and sees a fireman at the door, who has been waiting there for 45 minutes. Interrogated on the subject of how can that be, the fireman reveals that he had seen no one when the bell had rung the first two times, but it was he who had rung the third time, then hid, as a joke. He recites experimental fables, such as The dog and the Bull: 'another bull asked another dog: why did you not swallow your trunk?- Sorry, the dog answered, it's because I thought I was an elephant.' Their talk is interrupted by the Smith's maid, Mary, who wishes to express her own anecdote, but the two couples are affronted that a mere servant should do so. The maid is recognized by the fireman as a long-lost love of his, a woman who &quot;extinguished my first fires,&quot; he says, and Mary agrees to have been &quot;his little fountain&quot;. When she attempts to recite at least a poem entitled &quot;The fire&quot; the Smiths push her out of the room. Before leaving, the fireman asks about the bald primadonna. &quot;She covers herself as usual,&quot; Mrs Smith responds. After the fireman leaves, the two couples have an increasing amount of difficulty in understanding each other, then run about confusedly.

==&quot;Rhinoceros&quot;==

[[File:Rhinoceros.png|thumb|For some absurd reason, human beings are transformed into rhinoceros]] 

Time: 1950s. Place: Paris, France.

Text at https://archive.org/details/in.ernet.dli.2015.167320 https://archive.org/details/in.ernet.dli.2015.58383

John scolds his friend, Berenger, for his excessive drinking and disordered life. Unexpectedly, their conversation is interrupted by a rhinoceros running in the streets. They discuss where the animal could possibly have come from, but each suggestion seems more implausible than the other. Berenger's fellow office worker, Daisy, comes over to talk about the same subject. Once again, the conversation is interrupted by a rhinoceros, this time running in the opposite orientation. A housewife comes over to moan over the fact that the rhinoceros crushed her cat. John, Berenger, and Daisy discuss whether it is the same rhinoceros or a different one. A grocer thinks it is the same, but John disagrees, explaining that the previous one had two horns, therefore an Asian one, whereas the second one had only one, and thus of African origin. Taking into consideration the speed with which they were running, Berenger casts doubt on whether his friend could reliably count the number of horns. &quot;In addition, it was covered with dust,&quot; he adds. In his view, John is a pretentious pedant. John is offended. An old man intervenes to ask whether the one-horned rhinoceros is truly African? John and Berenger quarrel about that subject as well. According to Daisy, both are wrong. &quot;The Asian rhinoceros has one horn, the African one, two, and vice versa,&quot; the grocer pronounces. After John leaves angrily, Berenger has qualms about his own attitude, along with that of his friend. &quot;The least objection makes him froth at the mouth,&quot; Berenger declares. A logician comes over to say that even if the first rhinoceros had two horns and the second only one, there is still no conclusive evidence that the two are different, because the first one might have lost one. In the office where Berenger works, there is a difference in opinion concerning the existence of the rhinoceros. His fellow-worker, Botard, considers them an invention, an opinion that offends both Berenger and Daisy. In contrast, another office worker, Dudard, in love with Daisy, believes her eyewitness account. &quot;He does not even know how many he saw,&quot; Botard says of Berenger. After viewing a rhinoceros in the street, another office worker, Mrs Beefsteak, rushes in panic. One rhinoceros damages the staircase in the office building so that the workers are unable to get out. Yet Botard continues to deny their existence until he sees one of them himself. Mrs Beefsteak recognizes one rhinoceros at the door as her husband. Berenger sees one animal with two horns, but is still unsure whether it is Asian or African (unaware that the latter is true if it is white or black). Meanwhile, the department head, Butterfly, encourages all of the workers to return to work while Daisy telephones for help. Mrs Beefsteak seizes the opportunity of running away with her rhino-spouse by jumping from the elevated floor directly on its back. Botard pretends to know what is behind the arrival of the rhinoceros, but is unwilling to divulge it at the moment. In the emergency, firemen arrive to usher the workers out of the building. Feeling qualms about their dispute, Berenger visits John's home to apologize, but is horrified on seeing his friend turn into a rhinoceros before his very eyes. Butterfly and Dudard follow the same pattern with the growing crowd, as does Daisy, especially after hearing their voices on the radio. Against the transformation at all costs, Berenger resists the temptation to turn into one of them.

=Samuel Beckett=

[[File:Samuel Beckett 01-2.jpg|thumb|Samuel Beckett's plays depict the terrible and humorous side of tragedies, 1970]]

Samuel Beckett (1906-1989) continued or perfected, some would say, the Theatre of the Absurd with &quot;Waiting for Godot&quot; (1952), &quot;Endgame&quot; (1957), and &quot;Happy Days&quot; (1961). 

Waiting for Godot “marked a clear break with the dramaturgy of the 1940s and...established a new frame of reference for contemporary theatre...Where ‘Waiting for Godot’ seemed initially incomprehensible to its first...audiences...its meanings are now self-evident” (Innes, 2002 p 307). The play’s “structure emphasizes mythical or ancient time: the cycle of the day, the year and the seasons, inscribed in nature’s movements (the planets, stars, etc). It challenges the validity of linearity as the accepted structural model of modernity by undermining ideas such as certainty and progress” (Toribio Vazquez, 2022 p 161). “Who...is the unseen Godot? To some, he is death, to others, life, to a few, nothing...one could probably settle on Godot as standing for God...His absence does not signify negation...but...infinite possibility” (Bennett, 2011 pp 27-43). “Vladimir and Estragon...are clearly derived from the pairs of cross-talk comedians of the music hall...Vladimir remembers past events, Estragon tends to forget them as soon they have happened. Estragon likes to tell funny stories, Vladimir is upset by them. It is mainly Vladimir who voices the hope that Godot will come and that his coming will change their situation, while Estragon remains skeptical throughout” (Esslin, 1974 pp 26-27). “Vladimir thinks more, he is more cultured, his anguish is more intellectualized, he is more hesitant and demanding in his choice of words. Estragon is more spontaneous and more lethargic, he is more childish, he sulks more, he is more eager for protection, he is more egoistical and more obstinate, he holds to his own vocabulary and refuses Vladimir’s nuances. Vladimir is more restless, more active, Estragon more inert. Vladimir has the responsibility: he is in charge of the carrots, radishes, and turnips that constitute their meals. Estragon is more the victim: he is kicked by Lucky. While Vladimir tries to make conversation with Pozzo and to seem well-bred, Estragon listens only because he is threatened or ordered to; otherwise, he independently follows the flow of his own thoughts” (Guicharnaud, 1967 p 236). &quot;Didi is the contemplative, the listener, the seeker, the one expecting messages, the ascetic, the one who suppresses his physical side, while Gogo is the active, the non-reflective, the one who tries to wipe the tears from the eyes of sufferers, who must eat when he is hungry, and who bellows when he is hurt. Neither can do without the other&quot; (Baxter, 1965 pp 10-11). “Estragon, who's nickname is Gogo, is of the earth. His name is French for ‘tarragon’, an aromatic herb used as a seasoning in pickling. His obsession with his ill-fitting boots that cause him pain indicates that he is close to or of the earth. Gogo also goes and comes. He is the wanderer who always stumbles back to his companion Didi. He can be sarcastic and skeptical, but mostly he is resigned to an inevitably unhappy fate. Vladimir, whose nickname is Didi, continually looks and feels into his hat, seeking cooties or some other irritant, just as Gogo is tormented by his ill-fitting boot. He is more rational and less emotional than Gogo. Vladimir seems more in touch with the outside world and more aware of his immediate world. He is better spoken than Gogo, and he sings in both acts. He is the leader of the pair, and, significantly, he is the one who most believes in Godot...Pozzo is a sadist, enjoying his power over his slave, Lucky, but he is also weary of the relationship. After all, a master is always tied to the slave who serves him…Pozzo stands for capitalism exploiting the worker, Lucky. The derby or bowler hat enforces this consideration. Pozzo is all materialism, concerned about his baggage, his comfort, his food, his pipe, and his watch. Lucky has nothing but his hat and his burdens. Lucky is a slavish masochist who does not want relief from his pain and thus attacks Estragon. The fact that he does not take advantage of Pozzo's blindness in act 2 to escape or kill his enslaver indicates that he has need of the relationship and even the punishment. Lucky is not only a symbol of the exploited worker in a capitalist society but also the tormented intellectual made ineffectual by that society. It may be that Pozzo and Lucky are yin and yang in their relationship: part of one personality or entity” (Sternlicht, 2005 pp 54-55). “Serious subject matter is presented in music hall form...Much of the surface is taken up with farcical satire of conventional social behavior. Pozzo, for example, is unable to take a simple action like sitting down without an attendant barrage of ceremony, and the two tramps are always trying to strike up what will pass for a polite conversation, using catch-phrases like Vladimir’s: ‘this is not boring you, I hope?’” (Gascoigne, 1970 p 186). &quot;What makes the play more than just a pastiche of clown and music hall comedian is partly the philosophical overtones and partly the self-conscious elements...The characters watch themselves act, reflect at the very moment of acting on the significance, or absence of significance, of those actions” (Bradby, 1991 p 59). “Beckett’s extraordinary feat of blending pathos and comedy is accomplished by the relationship of the human characters who are, despite their bloviated portentousness and inane banter, filled with enormous charm. They are hilarious as they are tragic, exquisite amalgams of clownishness and grandeur. They can be pompous and stubborn, yet just as quickly brought down to earth with humility and despair” (Krasner, 2012 pp 343). According to Durán (2009), The play &quot;reflects Albert Camus' 'The myth of Sisyphus' (1942)...For Camus, the absurd issues from the clash of two contradictory phenomena: rational man and an irrational world...It soon becomes clear that Vladimir and Estragon live in a world wholly devoid of reason. The characters engage in pointless acts, the dialogue abounds in non-sequiturs and contradictions, and memories are short. Characters often forget whom they know or what they know. In Beckett's play, things happen not according to any logic or order, but as a result of sheer fortuity...Vladimir and Estragon thus find themselves disoriented and alienated from the irrational world they inhabit...Consequently, the two characters spend most of their time and energy devising ways to fill the emptiness of their mundane lives...Camus explains that one continues to live this type of absurd existence largely out of habit...But Camus warns that the protective walls of habit can unexpectedly fall away making one suddenly aware of life's absurdity...Thinking poses a danger because it can expose one to that 'suffering of being' provoked by a consciousness of the absurd...Suicide affords one means of escape...After learning from the young messenger that Godot will not come that day, Estragon gazes at the tree and laments... He asks Vladimir to remind him to bring a rope the next day and recalls a past attempt at suicide...The rejection of suicide still leaves the possibility of eliminating the other opposing term: an irrational world. Despite all evidence to the contrary, one may choose to view the world as truly rational. Camus calls this strategy 'the philosophical suicide'...By adopting systems of belief such as religion, philosophy, astrology, or what have you, one imposes a false logic and order on this world...Lacking the courage to commit physical suicide, Vladimir and Estragon find solace in philosophical suicide. They see their hope in the coming of a Godot, someone who will satisfy all their wants and needs...No matter what occurs, Vladimir and Estragon cling tenaciously to their hope in Godot's appearance...As a result, the two tramps end up doing nothing...Camus believes that an authentic response to the absurd resides in neither physical nor philosophical suicide...Rather than elude the absurd, one must not only accept but also sustain its truth, constantly confronting its reality through what Camus calls a metaphysical revolt...In the final pages of his essay, Camus illustrates his concept of 'revolted man' through the character of Sisyphus...[who] chooses instead to embrace his fate, fully conscious of all that that implies. [But the tramps] incarnate, in fact, the exact opposite of Sisyphus. Rather than embrace their reality, the two tramps use every means available to evade it&quot; (pp 982-989). “Vladimir and Estragon play the game of waiting for an entity that they have invented to save them from the unknowable. They have even hired a boy/priest to reassure them at regular intervals that they are not waiting in vain. Meanwhile they eat, sleep (and have nightmares), engage in futile philosophical discussions, and otherwise parody human existence” (Wellwarth, 1986 p 71). &quot;In Waiting for Godot, auditory and visual scenic means convey the tension between comedy and tragedy to the audience. Act Two ends in nearly an identical way to Act One. Estragon and Vladimir discuss suicide and separation. A tree, the only permanent prop in the play, has sprouted four or five leaves. However, what might signify the meaningful fullness of life the participation of humanity in a scheme of things larger than itself, a metaphysical reality capable of supporting the form of tragedy is reduced to mere occurrence&quot; (Como, 1989, pp 68-69). Brater (2003) emphasized the movement of the play from the particular to the universal, as in Vladimir's following comments to his fellow tramp: 'let us do something while we have the chance. It is not every day that we are needed. Not indeed that we are personally needed. Others would meet the case equally well, if not better. To all mankind they were addressed, those cries for help still ringing in our ears! But at this place, at this moment of time, all mankind is us, whether we like it or not. Let us make the most of it, before it is too late'&quot; (p 145). “The clearest statement of Beckett’s belief in the uselessness of thought is in the tremendously effective scene of Lucky’s tirade in Waiting for Godot. Beckett here implies that it is only in modern times that man has become impotent in thought and action” (Wellwarth, 1971 p 46). Lucky’s tirade &quot;is one magnificent moment when a bestially slave-driven underdog bursts into an incoherent speech which gives an extraordinary Joycean impression of overcharged meaning&quot; (Williamson, 1956 pp 69-70). “We have no superficial allegories and personifications of abstractions, but characters who are both symbolic and real in a situation which is a metaphor of the human condition...This is the true metaphysical Pascalian and Kierkegardian absurdity and nonsense of life without God or purpose and it is something which is very remote from the dehumanized, incoherent world of Ionesco...The Pozzo-Lucky relationship is the mirror of human degradation and shallowness. Pozzo hides his insignificance and hollowness under a cloak of ritual gestures and ceremonies which are part of the social apparatus of power...Lucky is merely an object, a thing, and his life is reduced to mechanical reactions; he not only serves Pozzo, he has also to think for him; he is therefore materially and spiritually Pozzo’s slave and has no individual existence” (Chiari, 1965 pp 68-74). The tramps “appear as a social unit outside society...like prisoners free to amuse one another...It is as though they ad lib for their very lives...The play takes up themes of many kinds- religious, philosophical, psychological- without any of them to become the drama’s motif, and with a fierce comic opposition to their pretensions...Pozzo and Lucky are emissaries from the realm of time and from the life of society, with its institutionalized relationships, its comforts and delusions, above all its thirst for hierarchies...the principles of human power and exploitation, delusory, ultimately disastrous, but maintained by them as the foundation of their lives...Whenever a character appears to be feeling some definite emotion or to have entered some decisive area of commitment, it is all undone by an opposite remark, a corrosive scornfulness, a physical jape” (Gilman, 1999 pp 242-250). “The word ‘divine’, used three times in the play, is spoken not by the seekers for Godot but by the slave commanded to ‘think’, the broken-down scholar, Lucky, in his wild meditation on the existence of ‘a personal God [including] referring to the ‘divine Miranda’, which points us to Shakespeare’s heroine in The Tempest, someone able to suffer ‘with those who for reasons unknown but time will tell are plunged in torment’. That she could so feel for total strangers understandably makes her ‘divine’ for the maltreated Lucky” (Worth, 2006 p 239). “Sober expression of misery is rare in this nearly wholly stichomythic play whose words are never allowed to inflate the period. The words remain simple, idiomatic, slangy” (Grossvogel, 1958 p 329).

Endgame &quot;reveals a singleness of tone and a tenacity of purpose that commands respect and bafflement...Nothing happens in Endgame and that nothing is what matters...The bitterness matters...the sense of entrapment matters...the intensity of Hamm’s contempt matters...the elegiac mood matters” (Gassner, 1960 pp 256-258). “Hamm is paralyzed and can no longer stand. His servant, Clov, is unable to sit down...some great catastrophe, of which the characters in the play are or believed themselves to be sole survivors, have killed all living being...Hamm is untidy. Clov is a fanatic of order. Hamm's parents are grotesquely sentimental imbeciles” (Esslin, 1974 p 41). Hamm might be an abbreviation of hammer, Clov might reflect “clou” or nail, from which may be derived Nell (or nail) and Nagg from the German translation “Nagel” (Mendelson, 1977). &quot;Nagg and Nell in their dustbins appear to be pawns; Clov, with his arbitrarily restricted movements ('I can't sit') and his equestrian background ('And your rounds? Always on foot?' 'Sometimes on horse') resembles the Knight, and his perfectly cubical kitchen ('ten feet by ten feet by ten feet, nice dimensions, nice proportions') resembles a square on the chessboard translated into three dimensions. He moves back and forth, into it and out of it, coming to the succor of Hamm and then retreating. At the endgame's end the pawns are forever immobile and Clov is poised for a last departure from the board, the status quo forever menaced by an expected piece glimpsed through the window, and King Hamm abandoned in check&quot; (Kenner, 1961 pp 156-157). &quot;Constant reference is made to the question of game, of play and theatre. Hamm opens his first and last monologues with the words, ‘Me- [he yawns]- to play’. To Clov’s question ‘what is there to keep me here?’, he replies, ‘the dialogue’. Hamm acts with knowledge of the underlying theatrical conventions and rules of performance, ‘Since that’s the way we’re playing it...let’s play it that way’. He teaches Clov: ‘An aside, ape! Did you never hear an aside before? [Pause] I’m warming up for my last soliloquy’. He begins and ends the play theatrically: at the beginning he makes the curtain rise (‘he removes the handkerchief from his face’ and at the end he lets it fall (‘he covers his face with handkerchief’&quot; (Fischer-Lichte, 2002, p 331). This type of self-consciousness is the epitome of the post-modern style in literature, in contrast with the lack of self-consciousness of previous periods. &quot;Hamm’s concern for all the actions of the day to be carried out precisely, and especially his obsession with being placed at the dead centre of his room, bear the shape of a man trying to establish his own dignity and importance, an attempt that is made absurd by his setting” (Bradby, 1991 p 70). “The tension between entropy and order, between strength sapped and the tenacity of will, between physical restraints or incapacities and the energy to play- the tension of a play of impasse- is central in Endgame. This tension is objectified in the relationship between Hamm and Clov. Finally dying...Hamm asks for ‘a few words’...Clov’s answer is a vision of the beauty of art and order...Hamm cannot match it and he concedes defeat...Clov says he is leaving the cell, the structure, but we see him silhouetted in the shadows...his eyes fixed on Hamm till the end...Hamm...thinking himself alone in the structure, dies alone” (Rosen, 1983 pp 275-276). “Nagg and Nell are a side bar commentary on the action of the main characters. Nagg and Nell represent an even more dysfunctional clown pair than Hamm and Clov. They are given space to do routines, but are prevented from achieving any clownish physical action because they are confined to ash cans. As a result, they are reduced to telling jokes” (McManus, 2003 p 79).

”Happy days&quot; &quot;is another Beckett threnody on the sorry lot of mankind reduced to an absurd stalemate from which man can only decline into a worse one...At the same time, one encounters another tribute to human endurance and the determination to shore up inner defenses of faith or delusion against failure, never yielding an inch to sentimentality, against which the writer defends himself with sustained irony, so that human heroism also appears to be a ridiculous capacity for self-delusion” (Gassner, 1968 p 504). &quot;On the one hand it is tragic that Winnie should be so cheerful in her terrible and hopeless predicament, on the other it is funny; in one sense her cheerfulness is sheer folly and the author seems to make a deeply pessimistic comment on human life; in another sense, however, Winnie's cheerfulness in the face of death and nothingness is an expression of man's courage and nobility, and thus the play provides a kind of catharsis, Winnie's life does consist of happy days, because she refuses to be dismayed&quot; (Esslin, 1974 pp 59-60). &quot;Winnie...buried to the waist and later to the neck, maintains a logician's, a grammarian's detachment from her plight...Though the earth now turns so slowly that through the intensely hot day she feels her body menaced by spontaneous combustion ('oh I do not mean necessarily burst into flames&quot;), yet she considers with some agitation whether the hairs or hair one brushes and combs are properly styled 'them' or 'it' ('Brush and comb it? Sounds improper somehow'), and feels it outweighs the day's miseries to have learned the proper definition of 'hog'&quot; (Kenner, 1961 pp 93-94). “Winnie’s strangest characteristic is her happiness...Winnie is resigned, eager to devour any old untruth, even poetry, to make use of any “pillow of old words” for her head...Winnie is a victim, a victim of the human condition...She has the usual consolations of existence: she tells herself stories, she has her bag, her hoard of miscellaneous possessions…Nevertheless, her most formidable weapon of defense against the absurd is her indifference” (Coe, 1986a pp 163-164). In Winnie’s song, the banal words of The Merry Widow waltz are lifted, by its lilting tune and the shocking contrast between the song and the brutally immobilized singer, into another dimension where the dance might go on forever, like the memory of the wedding day and the words of love once spoken” (Worth, 2006 p 242). “Human beings are sinking even as they embrace the illusion of love and mutter worn-out words. Winnie and Willie’s companionship is absurd, futile, grotesque, and pathetic, yet it is also somehow touching, for what else is there?” (Sternlicht, 2010 p 109).

“For all its intellectual game-playing and intertextual referencing, Beckett’s theatre of failure is rigorously non-conceptual. The aim is not so much to make us think as to make us feel, to produce evocative atmospheres that get under the skin and produce intense, dislocating experiences” (Lavery, 2015 p 28).

==&quot;Waiting for Godot&quot;==

[[File:En attendant Godot, Festival d'Avignon, 1978 f22.jpg|thumb|Estragon (played by Rufus) and Vladimir (played by Georges Wilson) are anxious about whether Godot will ever arrive. Avignon Theatre Festival, 1978]]

Time: 1950s. Place: France.

Text at https://resources.saylor.org/wwwresources/archived/site/wp-content/uploads/2011/01/Waiting-for-Godot.pdf

Two vagabonds,Vladimir and Estragon, expect to meet a man named Godot on a country road, who promised to be there, but has not yet arrived. While waiting, the two friends attempt to amuse themselves. Yet time passes and still Godot does not show up. Why? Have they mistaken the agreed-on day? Are they at the right place? Estragon is hungry but it is Vladimir who takes out a carrot and eats most of it. &quot;I'll never forget this carrot,&quot; he remarks amid his almost constant state of boredom. Their waiting is interrupted by the arrival of Pozzo and Lucky, the latter appearing to be Pozzo's servant if not slave and led along by him with a rope. This relation seems scandalous to Vladimir and Estragon, but they do nothing to interfere. Worse than this, Vladimir and Estragon begin to inflict the apparently mute Lucky with the same abominable treatment he receives from his master. But Lucky is not mute. He eventually bursts out with an unpunctuated monologue, incoherent in many parts and leading to nothing, after which he leaves with Pozzo. A young boy appears suddenly, sent by Godot to say he will drop by tomorrow. Vladimir is under the impression of having once experienced this event, but the boy denies it. The next day, nothing has changed except a tree has grown some leaves where they were before. Similar vaudeville-style exchanges are repeated to no avail. Although Vladimir mentions their waiting at the same place on the previous day, Estragon does not remember it. Pozzo and Lucky enter and soon fall down, but are not helped by either tramp, though Vladimir says it is necessary to do so and Estragon is willing to in exchange for money. Pozzo is now blind and Lucky mute, though the former does not remember when that misfortune occurred. They go on their way. The boy returns and leaves with the same message as the day before, without remembering what he had said on the previous day. As the only one seeming to remember, Vladimir's existence seems all the more futile. The two friends decide to hang themselves on the tree. If so, they will have an erection. Estragon takes off his belt and, vaudeville-like, his pants fall down. The belt snaps off before they get a chance to try it out. They give up. They decide to go but do not move.

==&quot;Endgame&quot;== 

[[File:Chess tablebase query.png|thumb|An endgame in chess occurs when the importance of pawns increase]]

Time: 1950s. Place: France.

Text at https://pdfcoffee.com/endgame-by-s-beckett-pdf-free.html https://edisciplinas.usp.br/pluginfile.php/3346220/mod_resource/content/1/ENDGAME%20BY%20SAMUEL%20BECKETT.pdf

Hamm puts off a bloody handkerchief from his face. Blind and unable to stand, he is served by Clov, sighted but unable to sit. While yawning, Hamm wonders: &quot;Is there misery loftier than mine?&quot; Hamm is frightened at the thought that perhaps he has not made Clov suffer enough, but is relieved on being assured that he has. Hamm's father, Nagg, lives in a trash-heap and asks for his pap. &quot;Accursed progenitor!&quot; Hamm cries out in anger. He commands Clov to give him a biscuit. Hamm despairs that nature has forgotten them, but Clov corrects him by saying there is no more nature. After lifting up the cover of his trash-heap, Nagg tries to kiss his wife, Nell, in the bin next to his, but is unable to. When Nagg laughs at Hamm's miseries, Nell scolds him. &quot;Nothing is funnier than unhappiness, I grant you that, but-&quot; she remarks but is unable to finish. Suddenly, Hamm decides he wants to be placed in dead center of the room. With great difficulty, Clov at last accedes to that desire. Hamm next requires him to look outside with a telescope, but the only thing visible is a grey landscape. Hamm has another frightening thought. &quot;We're not beginning to mean something?&quot; he wonders aloud. When a crablouse bothers Clov, Hamm commands him to kill it at once. &quot;Humanity might start from there all over again,&quot; he warns. He next asks for a catheter to expel urine, but before Clov can obtain one, urinates on himself. He then asks Clov to set the correct position of an imploring black toy dog. Soon after, Nell dies, at which Nagg weeps. After asking Clov several times whether it is time for his pain-killer, Hamm discovers there is none. It is useless to go on any further. Clov goes away. After whistling for him with no response, Hamm throws down the whistle and puts a bloody handkerchief over his face.

==&quot;Happy days&quot;==

[[File:Sketch of scene in Happy Days (play) by Samuel Beckett.jpg|thumb|Though half-buried in a sand-heap, Winnie tries ot get by. Sketch by an anonymous artist, 2011]]

Time: 1960s. Place: France.

Text at https://archive.org/details/happy_days_a_play_by_samuel_beckett

Winnie lies half-buried upright on a mound of earth. A bell from an unspecific source is the signal to start her day, in which she takes out comb, toothbrush, toothpaste, handkerchief, lipstick, nail file, appetite stimulant, glasses, and revolver. After taking them out, she kisses the revolver. Her husband, Willie, lives in a cave behind the mound, reading newspapers and postcards and pouring a soothing solution on his penis. She hears but does not see him. Under a parasol to protect her from excessive sunlight, she goes about her usual routine of the day, such as singing a song at exactly the same hour. As she chatters, Willie does not appear to be listening, so that she must strike him sometimes to get his attention. Music from an unspecified source is heard, at which she rejoices. Willie does not contribute much, but at least he manages to define the word &quot;hog&quot; for her. It is hot. Eventually, the parasol ignites from the excessive heat, but she remains optimistic that the day may yet end well. At the end of the day, the bell sounds again, at which time she puts each item back inside the bag except the gun. Winnie is content with little. “This will have been another happy day,&quot; she concludes. On a subsequent day, started by the same wakening bell, she now lies buried up to her neck and so can no longer manipulate any of her objects, though still confident this will yet be another of her happy days. She has not heard Willie for quite a while but believes he can still hear her, or, if not, to her he remains there in any case. &quot;Oh, no doubt you are dead, like the others, no doubt you have died, or gone away and left me, like the others, it doesn’t matter, you are there,&quot; she says. Unexpectedly, Willie shows up at last, heading towards her, or else towards the gun, but before reaching it, he falls off the mound. He manages to call out her name, at which she rejoices. &quot;Win! Oh this is a happy day, this will have been another happy day! After all. So far,&quot; she concludes for herself.

=Fernando Arrabal=

[[File:Fernando Arrabal.jpg|thumb|Fernando Arrabal's three major plays describe unusually frantic behaviors]]

Another proponent of the Theatre of the Absurd is the Spanish-born Fernando Arrabal (1932-?), notable for &quot;Le cimetière des voitures&quot; (The automobile cemetery, 1959), &quot;Guernica&quot; (1959), and &quot;Le grand cérémonial&quot; (The grand ceremony, 1963). As with the British Kitchen Sink school, the better plays seem to arise early in the dramatic careers of absurdists. He is also a proponent of Panic Theatre incorporating in Arrabal's own words &quot;chance, memory, and the unexpected&quot; to undermine official writing (Drumm, 2009 p 437), &quot;named for Pan and founded on the principle of the domination of the Dionysian&quot; (Farmer, 1971 p 155). “Homeric hymn 19 entitled ‘To Pan’ provides the most complete description of this god from whose name is derived the term ‘panic’ used by Arrabal. Pan was the god of shepherds, living in the high mountains...[Unlike Apollo’s sweet music, Pan plays] “primal matter...barbaric tunes on his rustic reeds” (Arata, 1982 pp 7-8).

In &quot;The automobile cemetery&quot;, “the cemetery becomes a symbol of the wreckage of civilization, of the moral destructiveness of technological society” (Podol, 1978 p 46). “The central visual image that gives shape to the micro-cosmos in which these characters struggle to cope with the senselessness of life on a day to day basis is the graveyard itself, filled with wrecked cars, a symbol of the destructive nature of modern civilization” (Podol, 1988 p 134). “Original goodness and the passion it leads to are the subject matter of The Automobile Graveyard, where, with great imagination, Arrabal peoples the stage with a miserable and actively sexual community lodged in the graveyard’s heaps of disabled cars. In their pitiful and comic midst, there appears a good trumpet player, accompanied by two other musicians. The hero is of course a slaughterer whenever he feels the urge, but he is called Emmanou, is eventually betrayed and beaten up, and at the end is carried across the stage tied to a bicycle, a woman wiping his face with a cloth. The transposition of the passion of Jesus is far too obvious, and the naivety of the symbol lessens the power of the play, which otherwise is rich in invention and meaning” (Guicharnaud, 1967 p 186). &quot;Perhaps more a visionary than a dramatist, [Arrabal] has the merit of being faithful to what he sees: his anonymous language- correct but without style, very similar to Adamov's- makes it impossible for him to cheat. He has seen the automobile graveyard, its characters, their gestures and their shapes; but when he bludgeons us with the Emanou-Christ symbolism, the effect is destroyed&quot; (Guicharnaud, 1962 p 119). &quot;The cyclic pattern is established in the dialogue from the opening moments of the play. The automobile junkyard, Arrabal's microcosm of contemporary life, is filled with abandoned cars, each housing an unseen clientele. As the guests settle down for the night in Act I, they are embraced by the maid Dila as usual, and we soon learn that the police 'are returning once more' in search of the three musicians who will escape as always...The circular structure found in the dialogue is carried over to the non-verbal aspects of the play. Continuously crossing the stage, the movement of the track runners and the cops and robbers is another component of the spatial dialectic. What we are witnessing here is an unresolved pilgrimage, unresolved because there is no center to this circle, no solution, no final destination. The runners Lasca and Tiossido are engaged in an empty peregrination which leads nowhere...Two opposing forces pursue each other: the pure and innocent on the one hand, the corrupted and the compromised on the other hand. The latter group, like Lasca and Tiossido, submit without question to regimented order, to forms filled out in triplicate, to rigorous training and discipline. They are commited to maintain the status-quo. Even the outcasts who live in the junkyard belong to this world, imitating its rituals which become grotesque parodies through the solicitous care of Milos. They are united with the strong to oppose the purity of an Emanou. It would seem that for once a truce has been proclaimed between the dominated and the dominants of the world under the egis of conformity...Dila plays the role of mediator in this world. She alone is lucid; she alone understands both the purity of Emanou and the degradation in which she lives. She too 'wants to be good', and hungers for purity, but she knows it is too late...She defends Emanou, hides him from the police, refuses to betray him for the reward. Yet she is impatient with his idealism and his blindness&quot; (Luce, 1974 pp 33-35). “The derelicts...are all adult children, innocent murderers, voyeurs, and exhibitionists. They like to urinate and make love. They hate the police but are constantly pursued by them...When we first meet Dila, she goes around like a great mother obliging all the inhabitants to bed down for the night. Then she gives herself to any male who desires her...Dila cynically reminds Emanou that that being good in such a world only causes trouble...and she is right...When he feeds some people in the crowd a few sardines and some bread, the others become jealous. Eventually his subversive activities lead to his pursuit by the police and his betrayal by one of his friends...Through Emanou, Arrabal...debunks the basic Christian ethic of charity and love...His good actions have little effect on his community and, we are to assume, no lasting effect whatsoever” (Donahue, 1980 pp 12-15). Emanou is meant to represent a shortened form of Emmanuel, Jesus Christ. His antecedents are similar, being born in a manger, son of a carpenter and Mary, feeding people in the crowd with fish and bread, remembered by a food item, betrayed by a kiss, and exposed in a crucified-like position. “The characters in the play become modern biblical figures...in the tradition of medieval mystery and miracle plays...Lasca and Tiossido...become Roman soldiers (policemen) who will arrest Jesus, Tiossido also impersonates Pilate, miming the moment when he washes his hands, Fodère...enacts the role of Peter, voicing the triple denial of Jesus, Dila...first resembles Mary Magdalen and later turns into Veronica as she washes Jesus’ face, Tope...impersonates Judas Iscariot, and Milos...finally turns into Simon, the Cyrenian who helped Jesus carry the cross” (Arata, 1982 pp 33-34 and p 68). “Milos generally dominates Dila; on several occasions he punishes her, once for not proffering sexual favors and, irrationally, another time for doing exactly that. Dila, however, aggressively threatens a cowering Milos with chastisement at another moment in the play. The drama’s circular structure derives from the physical movement of Lasca and Tiossido. Those two characters begin and conclude the work by seeking a new world record, but in reverse roles. Their relationship reflects the indomitable will of the ambitious mother and the male’s need to assert himself physically in response to the feelings of inferiority he experiences when he compares himself to the female. Lasca and Tiossido also represent the oppressive nature of the state. At the plays end, the absurdity of their confining, suffocating route is affirmed, and their potential to metamorphose into police serving the system remains unchanged...Emmanou commits murder and other socially unacceptable acts. He is convinced that he will be pardoned, however, because he has memorized the meaning of goodness...If Christ can be thought of as love, then both he and that emotion are abrogated by the mechanized, dehumanized world of the automobile graveyard. The graveyard itself constitutes a central, visual symbol of the wreckage of civilization” (Podol, 1986a pp 125-126). Arrabal’s play “is certainly an impressive piece of theater, full of wild energy and black humor, bitterness, mockery, and terror, and an innocent despair of the kind felt by children, who cannot fathom either the suffering they undergo or which they themselves cause” (Gilman, 2005 pp 179-180)

In &quot;Guernica&quot;, “Fanchou and Lira are at once innocent victims of the Spanish civil war and of all wars and representatives of the human weakness and insensitivity leading to destructive quarrels...Fanchou’s reluctance to exert himself to extricate Lira, his rebukes directed at her ignorance of the nature of war, Lira’s references to Fanchou’s sexual impotence and her utilization of the silent treatment are both humorous and disquieting in the context of the desperate situation” (Podol, 1978 p 51). “Lira’s entrapment in the toilet during the bombing of the Basque spiritual capital in 1937 creates the sort of tension between the horrifying and the comic that characterizes the grotesque. Her dialogue with her husband, Fanchou, which alludes to his sexual insufficiency and reveals their mutual selfishness and lack of true empathy indicts them without diminishing the horror of their plight and of the air attack itself. The villains of the work are the novelist and reporter, who demonstrate no concern for their country and its people and who seek to exploit the situation for their own professional gain...At the very end, encapsulation and pessimism are countered by the symbol of the balloons which cannot be shot down by the soldiers who have just killed Fanchou and Lira. Visually, Arrabal utilizes vertical movement for the purpose of affirming hope and liberation” (Podol, 1988 pp 134-135). &quot;When the town of Gernica, the ancient capital of the Basque people, was destroyed by the German air force on April 26, 1937, the officer in charge of the attack, Wolfram von Richthofen, and his entourage were watching from a nearby mountain. As is well known, an underlying interest of this assault, and, in general, of German participation on the side of the Nationalist forces during the Spanish Civil War, was to test new technologies of warfare. Von Richthofen and the audience gathered on Monte Oiz witnessed the staging of the first blitzkrieg style of intense bombing that would become central to Nazi strategy during WWII. The destruction of Gernica, from its first horrific moments, was a theatricalized event in which the largely civilian victims were unwitting actors...When the journalist appears, &quot;Arrabal presents a clear indictment of those who would benefit from an artistic rendering of the destruction of a civilian population: literary style subsumes any intent to depict accurately what has happened; the focus is placed not on the people who suffer but on the voice that presumes to tell their story&quot; (Drumm, 2009 pp 427-436).

In &quot;The grand ceremony&quot;, the protagonist “who whips dolls and murders a young girl is maintained in his psychotic state by the presence of an authoritarian and machiavellian mother” (Guicharnaud, 1967 p 185). The name of the protagonist, an anagram of the great lover, accentuates the strong note of grotesque deformation. Despite these parodical elements...The play also manages to capture the intense anguish of the protagonist...Cavanosa suffers from a complex caused by a fixation on the mother figure which does not allow him to integrate his two parents in his psyche or develop an independent personality and ego...Cavanosa’s reprehensible treatment of Sil is really a reaction to his growing fear of realizing his repressed desires. Death, violence, and eroticism intermingle; the mother’s incestuous longing for her own son takes the form of a wish to die by his hand and helps to explain the warped nature of Cavanosa’s own feelings of love, evidenced by his treatment of his dolls and Sil. Physical torture becomes an expression of internal strife, and physical deformity the externalization of psychic anguish. While these forces dominate, the play’s atmosphere remains subsumed by the world of the subconscious...Lys emerges as Sil’s alter-ego (affirmed by their common names which are palindromes of each other); she finds Cavanosa lovable and attractive because she has not had contact with other men...If his words introduce a note of ambiguity by suggesting that love is still only possible as a destructive act ending in death, his tender kissing of Lys and the fact that he speaks dreamily to her justify, at least partially, the feeling of hope for the protagonist’s liberation from the imprisoning influence of the archetypical devouring mother” (Podol, 1978 pp 65-66). “Not recognizing a moral standard, living in a world of his own obsessions, Cavanosa encounters with every entrance into the other world of the park a way of being and acting that is the very contradiction of his own...All of Cavanosa’s actions are the opposite of what one would expect: love brings forth only his scorn, any affection shown him incites him in anger, any kindness offered him produces a cruel reaction...The result is a character not only different from the others, but one who realizes he is different and is able to observe himself functioning with ironic distance...Unlike Sil, who had to be told what was necessary to please Cavanosa, Lys instinctively knows...Lys is the woman-child prostitute who is familiar to the early plays of Arrabal...[The worlds of Cavanosa and Lys] coincide. She was tied to her mother physically just as Cavanosa is tied to his mother emotionally; she makes whips, and he uses them; she paints dolls, and Cavanosa ‘loves’ them. Cavanosa’s mother is authoritarian, sadistically cruel, and classically vindictive. The power she exercises over her son is slowly failing, and she knows that she will soon be replaced by one of the girls Cavanosa meets in the park during his daily ritual...What is more, she knows that her son wants to kill her...She knows that her son does not have the strength to kill her, and consequently she ever so tenuously maintains control over him...His fear of impotency is in part allayed by his masturbatory activities with his life-sized dolls, and his oedipal anxieties are in part allayed by the daily wooing and murder of a girl he meets in the park. Cavanosa, however, is not able to distinguish between the fantasies and reality. In effect, his fantasies are his reality...until he meets Lys, who is able to participate in his fantasy world turned reality. Lys, of course, is only a replacement for his mother and his dolls. She allows him once and for all to externalize the relationship that he has imposed upon his mother and that she in turn has imposed upon him” (Donahue, 1980 pp 17-21).

&quot;Considering his plays as a corpus, one can classify the Arrabaldian universe by extracting eleven primary features:
1. A half-dreamed, half-mythical realm of youthful reverie, sometimes childish; a sort of playful quasi-paradise where children's naughty games turn into handcuffed and chained torture, even to unrepentant murder.
2. Unexplained co-existence of nostalgic, simple-minded childlikeness with adult ambiguities. (A mother-fixated hero, with tendencies to misogyny, is prototypical of this double nature).
3. Obsessive tension of victims confronting torturers, dramatized mythically.
4. Rapprochement of mirth and fright; similarly, grotesque to-and-fro swings of opposite emotions.
5. Role-multiplying or androgynous characters.
6. The police-state metaphor: inquisition, torture, despair, violent death, betrayal of one family member by another.
7. Inverted Christianity, mystic emblems, blasphemy, erotic sensationalism, bizarre ceremonies and rituals, alliance of wild eroticism and death; simultaneity of devout and sacrilegious motifs.
8. Fundamental counterpoint of illusions within illusions.
9. An impetuous, sometimes patchy style; an uneven, coursing, or savage dramatic rhythm dependent on extravagant shock effects.
10. Outlandish visual imagery: dwarfs, giants, hunchbacks, huge balloons, a robot chess player, whips, coffins, nude and voluptuous cadavers.
11. Mythical or metaphorical substructure, interconnecting various esoteric patterns of coherence&quot; (White, 1971 p 99).

==&quot;The automobile cemetery&quot;==

[[File:AUTOMOBILE GRAVEYARD - NARA - 545545.jpg|thumb|Conflicts arise in a junkyard inhabited by people]]

Time: 1950s. Place: France.

Text at ?

An energetic Lasca encourages an exhausted Tiossido to jog around a junkyard, while an elegant-looking butler, Milos, takes orders for next morning's breakfast among assorted people living inside old and discarded automobiles. Lasca also encourages his wife, Dila, to kiss her customers. On noticing her reluctance, he smacks her on each hand with a ruler. As Dila, heads towards various car occupants to offer sexual favors, she meets Emanou, born in a manger, son of a carpenter and a woman named Mary, who expresses a desire to lie with her. &quot;We will turn about, embracing, like two underwater squirrels,&quot; he proposes. She accepts. The next morning, Emanou announces that police officers are out to arrest him for playing the trumpet to the poor. Incensed on seeing Dila with a man, Milos grabs her by the hair and throws her down. On this day, the roles of Lasca and Tiossido are reversed, the latter appearing more energetic. When Emanou's friend, Topé, learns there is a reward out for his arrest, he offers to betray him to Lasca and Tiossido with a kiss. Undisturbed, Emanou offers Topé and Dila almonds from a bag. &quot;If ever the cops capture you, we'll eat the almonds in memory of you,&quot; Dila declares. When Topé kisses Emanou, Lasca and Tiossido promptly arrest him. After Tiossido wipes his hands of this event, they take Emanou out to be whipped. He is next seen on a bicycle with his arms stretched out, on which Dila wipes the sweat off his face before he is taken away. The next day begins as any other, with Milos and Dila at their regular chores.

==&quot;Guernica&quot;==

[[File:Bundesarchiv Bild 183-H25224, Guernica, Ruinen.jpg|thumb|Guernica, Spain, in ruins after being bombed, 1937]]

Time: 1930s. Place: Guernica, Spain. 

Text at ?

On her way to the bathroom, a bomb fell on the building, so that Lira lies buried under mounds of rubble from which her husband, Fanchou, cannot extricate her. He seeks to encourage her, but a fall of stones hurts her arm, which bleeds profusely. A writer and a journalist arrive to survey the damage caused by bombardments throughout the city of Guernica. &quot;Add that I am preparing a novel and perhaps even a film on the civil war in Spain,&quot; the writer declares.  To help pass the time with his wife, Fanchou suggests he tell her a story. &quot;Do you want the one about the woman who was in the bathroom and who remained buried under mounds of rubble?&quot; he asks. To amuse her further, he grimaces like a clown, but Lira is unable to see him. She asks whether the tree nearby is still intact; he answers that it is. While seeking yet again to save her, Fanchou is pushed by an army officer, who impedes his progress and then leaves without a word. Unable to accomplish anything further, Fanchou gives her a child's balloon. A woman and a little girl pass by, the former pushing a wheelbarrow containing dynamite. The balloon bursts, leaving Lira to complain about her condition. The army officer returns, who laughs while eating a sandwich, then goes away again. Fanchou asks Lira why she never had lovers. &quot;That would be chic,&quot; he asserts. &quot;You never think of me...When I take off your clothes in front of my friends, you always look disgruntled.&quot; When suggesting she would perhaps be comforted by the presence of a priest, she reminds him that they are atheists. &quot;Who, us?&quot; asks a surprised and frightened Fanchou. The woman and the girl return, the woman carrying on her back armements of various kinds. Fanchou becomes all the more frustrated at being unable to help his wife. &quot;It's your fault. Such a mania you have, reading in bathrooms!&quot; he blurts out. The woman and the girl pass by a third time, pushing a cart containing old guns. Now Fanchou suggests that Lira might write down her will. While attempting one last time to save her, he is buried underground himself, a victim of yet another bombardment. The woman returns, this time without the little girl, carrying a coffin. Two balloons rise heavenward. The officer tries to shoot them down, but is unable to. The voices of Fanchou and Lira are heard above, laughing.

==&quot;The grand ceremony&quot;== 

[[File:Life Size Doll at AVN Adult Entertainment Expo 2009.jpg|thumb|A modern Casonova collects life-size dolls to present to himself the grand ceremonial]]

Time: 1960s. Place: France.

Text at ?

A hump-backed Cavanosa type meets by chance a woman named named Sil in a public park. Alhough he appears rough, she agrees to stay with him. Her boyfriend, kind and considerate, shows up to take her away, but she prefers to stay with the rude stranger, until he tells them both to go away. She does so but then returns armed with a whip. He nevertheless becomes even ruder, kicking her and trampling over her. Then he asks her to wait outside his house for a light signal, where she may help him remove his mother's body, whom he says he has recently murdered. However, his mother is not dead. She begs him to avoid women, who would only steal his money. He sits on her knee, then brings her as a gift a small coffin containing a doll. She calls him a monster, which he deprecates. She next asks to see his knife and then requests him to strike her with it, but he cannot. They appear to be reconciled somewhat. Then she bites him on the mouth and starts to reminisce. &quot;Another time, when you did not want me to go out without you, you nailed your hand on the door leading outside, threatening to stay like that until my return,&quot; she reminds him. She notices legs protruding from beneath his bedcovers, which he explains as being one of his dolls he is in the habit of caressing. When the mother leaves, Sil knocks and enters the room. When Cavanosa dresses her up as a Christ-like figure, she agrees to die for him. She also notices the legs beneath the bedcovers. It is not a doll but a dead woman dressed exactly as she is, whom she helps to carry behind a screen. Sil's boyfriend shows up again, to whom Sil explains what she has done in the room, but when she sets aside the screen to show the carcass, it is no longer there. Cavanosa suddenly appears and grabs the boyfriend, ties him up, and threatens him, but, in the end, lets him go. The mother returns and watches outside the window while police officers take away a body, explained by Cavanosa as the one he killed the day before yesterday. &quot;I told you not to leave her in the cellar,&quot; she reproaches him. Cavanosa wants Sil to go away, but she insists on staying until he agrees to turn her into her mother's slave. The next night, he meets another woman named Lys, with a similar disposition as Sil's. He is rude to her also, but yet she still wants to remain with him, retrieving for him a whip taken out from beneath her skirt. He decides to take a doll out from his car and go away with her.

=Jean-Claude Brisville=

In post-absurdist theatre, there are several trends of note, including the return of history plays, though largely imagined in the case of &quot;L'entretien entre M. Descartes avec M. Pascal le jeune&quot; (The dialogue between Mr Descartes and the young Mr Pascal, 1985) by Jean-Claude Brisville (1922-2014), based on the single meeting of the two mathematicians and philosophers in 1647. Brisville also wrote two other history plays: &quot;The supper&quot; (1989), based on the conflict between the 19th century statesman, Talleyrand, and the minister of the police, Joseph Fouché, and &quot;The antechamber&quot; (1991), based on the relation between Marie, marquise du Deffand, and Julie de Lespinasse. Her eyes failing, the marquise brings over to her house a bastard daughter of her brother, Julie, as her reader. The marquise's house first attracts intellectuals of all sorts until she distances herself from the most liberal ideals taken up by Julie, whose antechamber draws jealousy from her protectress, from whom she is forced to leave.     

==&quot;The dialogue between Mr Descartes and the young Mr Pascal&quot;==

[[File:Frans Hals - Portret van René Descartes.jpg|thumb|Portrait of René Descartes (1596-1650) from a drawing by Frans Hals (1580-1666)]]

[[File:Blaise pascal.jpg|thumb|Drawing of Blaise Pascal (1623-1662)]]

Time: 1647. Place: Paris, France. 

Text at ?

René Descartes meets Blaise Pascal, two mathematicians and philosophers with a particular interest in religion. Descartes admits that so far, knowing the dangers inherent in expressing opinions about religion, he has &quot;advanced masked&quot;. Unlike Descartes and despite his achievements in mathematics, Pascal is beginning to lose interest in science, because he is looking for certainties only religious faith can supply. Pascal is outraged at Descartes' faith in numbers. &quot;Can a Christian reason thus?&quot; he asks rhetorically, &quot;Don't you see that reason will make God superfluous to you?&quot; Descartes denies that. Fearing God and his swaying lack of faith, Pascal wishes to work only for his salvation, while Descartes is confident of that while at the same time working on scientific subjects. Pascal asks him to write a letter in support of a fellow Jansenist unjustly accused by Jesuits, the dominant movement of the time. Descartes refuses, for he has no wish to be involved in superfluous religious quarrels. Pascal is disappointed and accuses him of cowardice, which the other denies. Another subject of controversy is Madame de Sablé's decision of dancing the night on the same day she had received communion, which Descartes considers a trivial matter, to Pascal's astonishment. Pascal further alienates his fellow philosopher by declaring that he welcomes tribulations, for physical pains &quot;unite me with Christ,&quot; he says. Dismayed at Pascal's austerities, Descartes described an anecdote about a man who once saved his life when he was trapped beneath a horse and likely to freeze to death. That man, despite his charity and goodness, later lost his position as an ecclesiastic because of Pascal's accusations of his eccentric beliefs and has now become a pauper: is this serving God? Descartes concludes by opining that matters relating to the dangers of damnation are debatable and that no certainty is possible. Pascal does not agree. &quot;The all I aspire to is beyond mathematics,&quot; he affirms.

=Bernard-Marie Koltès=

Also of note in the post-modern period stands Bernard-Marie Koltès (1948-1989) with &quot;Le retour au désert&quot; (Return to the desert, 1988).

In Return to the desert, “although Koltès’ play does not explicitly state it, Mathilde and her children are ‘pieds-noirs': French settlers in colonized North Africa. Numerically weak but economically and politically powerful, the ‘pieds-noirs’ were an ethnic minority but belonged to the dominant colonial class. By the end of the war 90 per cent- around one million- uprooted and repatriated to France owing either to the conflict or to the fact that they were no longer welcome in an Algeria seeking independence…Mathilde exiled herself to Algeria after being shamed by her family and the French authorities for a liaison during the Second World War with a German soldier, which presumably produced her son Édouard, born around the time she left...Mathilde’s daughter Fatima is presumably of Algerian parentage, given her Arabic name” (Delijani, 2024 pp 370-374).

&quot;Mathilde’s arrival &quot;disturbs everything in the upper bourgeois household: the relationships within the household, where Adrien is kept in a state of dependency and where his second wife, Marthe, is drunk most of the time, as well as the relationships outside the town, where a clubby contacts with the local powers will be upset. Mathilde provokes this revolution partly out of sheer cussedness, partly because she wants to regain her part of the inheritance and partly because she is genuinely upset at the death of a first wife, Marie...Mathilde and Adrien can only relate to one another through activities of barter and exchange, and their children become commodities just as much as the house and factory that they have inherited from their father” (Bradby, 1991 pp 276-277). &quot;Violence simmers in every scene, from the very beginning when Mathilde Serpenoise, returning from Algeria to her ancestral home, is unable to greet her respectable bourgeois brother, Adrien, without the pair insulting one another. This scene is comic because of the ironic distance set up between Adrien's pretensions to middle-class dignity and the vicious dog-fight that in fact breaks out between him and his sister. The violence in this play is constantly viewed in an ironic perspective. Towards the end of the play, the city fathers (including Adrien) are involved in a successful plot to plant a bomb in an Arab café. At the time when the bomb explodes, Adrien's own son is inside, seeking sexual adventure, and when he staggers home, bleeding, to confront his father, all Adrien can do is to slap him for being out of the house without permission&quot; (Bradby, 1994 pp 377-378).

“Exiles, foreigners, and outsiders are [strangers] who inhabit Koltès’ dramatic landscapes. So many of his characters are on the run so to speak, having left the homeland for a country where their difference is both visible and audible. Mathilde questions her homeland in Return to the Desert. ‘What country do I belong to?’ she asks. ‘Perhaps your home is the place you're not at?’...Mathilde is condemned to wander a landscape where she hovers between foreigner and native. She first appears as a refugee from the escalating conflict in Algeria; she left Metz fifteen years earlier having been publicly humiliated by her brother and his cronies she leaves Metz for a second time again at the end of the play with her bickering brother in tow...For Mathieu...families are simply about inheritance; coercive structures where misogyny is passed from father to son, children are raised through ‘kicks and wise precepts’, and fathers trapped forever in a destructive adolescence, a life spent with school friends indulging in conspiratorial games...Masculinity is exposed, wounded, embattled, and threatened in the worlds created by Koltès. In Return to the Desert , it is articulated by Adrien's impressionistic son as ‘slapping other people's faces...mates to drink with and fight with...enemies to kill and defeat.’ Its workings are exposed and ridiculed as the farcical camaraderie of the town officials (represented by the prefect of police, solicitor, prefect of the department, and Adrien) in scene 9, plotting behind closed doors against those who question their excesses” (Delgado, 2011 pp 28-31).

“Koltès’ plays are distant from narrative-driven traditions of contemporary dramatic writing. The behaviour of his characters is constantly surprising, resisting the operation of psychological cause and effect that lies at the heart of much realistic playwriting. Koltès’ plays celebrate unpredictability and that which lies unsaid; they have an antipathy to the realistic depiction of character habitually associated with method acting” (Delgado and Bradby, 2015 p 141).

==&quot;Return to the desert&quot;==

[[File:Dunes of Algeria.jpg|thumb|After spending 15 years in Algeria, Mathilda discovers an even worse desert in France. Photo of dunes in the Algerian desert]]

Time: 1960s. Place: France. 

Text at ?

After fifteen years of absence in Algeria, Mathilda returns to France with her daughter, Fatima, and her son, Edward, in the house left occupied by her brother, Adrian, who assumes she has returned for only a brief stay. Not so, as she specifies from the start. She intends to remain in the house that belongs to her, just as the factory belongs to him, as decided when their parents died. Adrian is upset, being responsible for the improvements he has made to the house, and so to some extent rightly his as well, but nevertheless forced to accept. When his son, Matthew, insists on continuing to have a room of his own instead of sharing it with Edward, he smacks his face. Fatima confesses to her mother she has met someone in the house garden, but when asked who it is, she refuses to tell. In the garden, Adrian catches Matthew trying to leave the family grounds to join the French army in the Algerian war of independence (1954-1962). &quot;I do not want to inherit,&quot; the frustrated Matthew declares, &quot;I want to die uttering beautiful phrases.&quot; Adrian prevents it. On seeing a police commissioner called Planters in the house, Edward jumps on him and immobilizes him. The bewildered man asks Mathilda about meaning of such an act. She answers that fifteen years ago, the man was one of those responsible for her exile, when he accused her of indecency for bearing a child out of wedlock. To humiliate him, she cuts his hair off. On seeing him thus exposed, Adrian suggests that the humiliated police commissioner may avenge himself by spying on Fatima and locking her up as a madwoman, all the more so because she pretends to have seen the apparition of his dead wife, Mary. Confronting each other with their separate needs, Adrian and Mathilda quarrel on several subjects. Adrian is especially worried about how Edward encourages Matthew to follow him in Arab cafes. Adrian strikes Mathilda who strikes him back. They are separated by Edward and a servant, Aziz. In the garden, Matthew tries to engage in amorous relations with Fatima, who repulses him. Unaware of this aspect, Mathilda encourages Matthew to continue friendly relations with both her children. A distraught Fatima points towards what seems to her as Mary's ghost, but her mother sees nothing. At night together in bed, Mathilda tells her daughter she feels she is in danger in her brother's house. She would particularly like to know how Mary died. Adrian enters to say that Matthew has been recruited in the army. He has no confidence that his son will come out of the war alive. When Fatima expresses her wish to return to Algeria, Mathilda does not answer. Adrian meets Planters and a lawyer, Borny, late at night to await developments about the bomb they planted at an Arab cafe. To their consternation, the explosion kills Matthew and Aziz. Adrian and Mathilda decide to move to Algeria, away from this desert of a house.

=Yasmina Reza=

[[File:Yasmina Reza at XIII Prix Diálogo - Ceremonia de entrega.jpg|thumb|In Reza's &quot;Art&quot;, men’s friendship is put to the test when one of them appears to have made a bad purchase]]

Still in the post-absurdist tradition, Yasmina Reza (1959-?) wrote &quot;Art&quot; (1994). “On one level, the play is a satire of the modern art market, [on the other] merely a pretence to explore the trials and tribulations of friendship” (Glynn, 2020 p 266).

“Reza probes the ambiguities of art and affection in scenes that are taut, ingeniously structured, and often hilarious...Does an art work have inherent value, or is value created by the market, or the era- or by a spectator's caprice? Is there such a thing as disinterested friendship?...Reza gauges the temperaments of her characters with a surgeon's precision, and the script's ever-changing currents of anger, resentment, and sympathy create astonishing suspense in a play that is basically one long discussion. The dialogue has the paradoxical versatility of an optical illusion: Serge, Marc, and Yvan criticize each other by criticizing art, and each betrays himself when attacking the other guy. And their quibbles over words and concepts (is it the white in the painting, or the idea of whiteness, that is so upsetting?) could admit them to a deconstructionists' convention” (Wren, 1998 p 2).

“Serge sees something worthy in that which Marc finds worthless. And this threat- ens their friendship…One of the earliest conceptions of friendship in Western thought is Aristotle’s notion of what he calls the friendship of character or character friendship. This is not the only type of friendship there is- there are also friendships based on such things as expediency- but, for Aristotle, character friendship is the highest sort. This is the type of friendship that obtains between equals, people of equal virtue and excellence...Aristotle suggests that without friends, friends who are our equals, we have no way of objectively assessing our own qualities, no objective measure of assessing whether or not we are virtuous or excellent. Genuine self-knowledge requires an outside viewpoint to validate it…Now if we suppose that the friendship between Marc and Serge is of this sort, then it is easier to understand the violence of Marc’s response. Serge’s incomprehensible appreciation, from Marc’s point of view, of the painting implies that Serge and Marc are not alter egos, and this, of course, threatens Marc’s and then Serge’s sense of who they are... If Marc and Serge are to sustain their friendship, they must in some way re-establish a shared sensibility. Marc must come to see something of value in Serge’s painting. And this, of course, happens, though through a very odd chain of events...Speaking figuratively, friendship has prompted Marc to see something in a new light, to find value where Serge does, though not exactly in the way that Serge does, and this makes possible a renewal in their friendship, underscoring the potential of art not only to confirm the existence of friendship, but the potential of friendship to expand the excellence, in this case of the sensibility, of the other self”  (Carroll, 2002 pp 200-206). Although Marc may be sincere in his new perception of the painting, his new opinion  can also be interpreted as the “renunciation in the desire for power” to secure a friendship (Karwowski, 2009 p 78).

&quot;Dermatologist Serge harbours artistic and intellectual  ambitions; aeronautical engineer Marc is more down to earth and finds the purchase of the painting, which he describes in no uncertain terms as 'that piece of shit', risible. The two men, each of whom has been successful in his chosen career, drag the third character, Yvan, into  their  argument. For  his  part, Yvan  sells  stationery  and  is  a  rather  clumsy procrastinator. Clearly, the play’s success is not entirely due to its plot, with its various questions: whether the friendship will endure despite personal stubbornness or social divides, whether or not the Antrios can be classified a work of 'art', or whether these 'single men' (one is divorced, one is experiencing marital problems, and the other is about to get married- his wedding takes place off-stage in the course of the play) can manage to construct a durable relationship. And neither is the play the sum total of its constituent themes, albeit ones that will be familiar to audiences on both sides of the Atlantic: the fragile nature of friendship, snobbery, money, social climbing, solitude, the pursuit of happiness, and the seditious role of modern art&quot; (Jaccomart, 2013 p 234).

The play “is fashioned around revelations about the power dynamics and the emotional contortions of modern male friendship. As the plot progresses, the characters all heavily criticize each other’s sexual partners, careers and familial failings. Throughout, the battle is conducted with a constant eye on the painting until Serge invites Marc to vandalize it with one of Yvan’s pens. Their relationship,  ‘destroyed by word and deed’, is renewed on what Serge calls a ‘trial basis’- the play ends where Marc looks afresh at the painting and instead of seeing a sea of white, sees ‘a man who moves across a space and disappears’. The play explores in part the paradox of both the divisive and the conciliatory power of art: through the disagreement about the painting the men deconstruct and then reconstruct their relationships with sharpened wit and, at one point, physical as well as verbal violence” (Gale, 2015 pp 197-198).   

==&quot;Art&quot;==

[[File:Edmond_Boissonnet_-_La_toile_blanche_n°2.jpg|thumb|Friends are puzzled after Serge’s purchase of a painting depicting white lines on a white background. “White painting no 2” (1985) by Edmond Boissonnet (1906 -1995)]]

Time: 1990s. Place: Loiret region, France. 

Text at https://pdfcoffee.com/art-yasmina-rezapdf-pdf-free.html http://pvp.org/Play%20Reading/ART%20by%20Yasmina%20Reza.pdf 
https://kupdf.net/download/art-the-play-yasmina-reza-english-pdf_59f0c2bbe2b6f598324f005f_pdf

Serge has bought an expensive painting by Antrios consisting of whitish lines on a white background. His friend, Marc, is devastated at his lack of judgment. To make light of the situation, he laughs. Serge does not. When Marc announces the purchase to his other friend, Ivan, the latter is much less upset. Ivan even says to Serge he likes the painting. Serge laughs light-heartedly, accompanied by Ivan. Serge tells Ivan that Marc's laugh was &quot;sardonic, without charm.&quot; When Ivan reports their talk to Marc, the latter specifies that Serge laughed just to please him, in no way for the right reason, because the painting is ridiculous. Serge reports to Marc that Ivan likes the painting. Marc reports he has had somewhat a change of heart, asking himself the question: &quot;Is the yielding to this incoherent purchase not a highly poetic gesture?&quot; Ivan is soon to be married but is in conflict with his girl-friend over the invitation card to the wedding. She wants her stepmother to be included on the card, but since Ivan detests his own stepmother, he refuses to have her included. Marc and Serge agree that he should cancel the wedding. But Ivan says he cannot, because his boss is her uncle. Marc is exasperated by Ivan's attitude, &quot;because he is a little courtesan,&quot; he says, &quot;servile, fooled by money, bluffed by what he thinks is culture, culture that I definitely vomit away, moreover.&quot; At this point, Serge challenges Marc. &quot;Who are you to impose the law?&quot; he asks belligerently. On his part, Marc is unable to come to terms that Serge likes the purchased painting while the latter is indignant that Marc is never hurt by his opinion. Serge specifies that he never voiced the negative opinions he holds about Marc's girl-friend. When Marc insists that his friend reverse his opinion of her, he refuses. They fight. In the scuffle, Ivan is inadvertedly hit on the ear. They stop to attend him. Marc at last reveals the main reason he is so upset about the purchase, that he can no longer represent himself as Serge's mentor in measuring all things by his opinion. To prove he considers their friendship more important than the painting, Serge permits Marc to damage it with a felt-tip pen, to Ivan's horror. Marc’s rendering changes his perception of the painting. He now sees value in that abstract work of art, though different from Serge’s view, which draws them closer. Serge and Marc are able to repair the damage. When asked whether he thought that the potentially damaged painting could have been repaired, Marc admits he did not think so it could. Serge lies by saying that he did not think so either.

=Jean-Marie Besset=

[[File:Jean-Paul Besset Europe Ecologie 2009-06-03.jpg|thumb|Besset showed conflicts arising between students at a prestigious business school. Photograph of the author, 2009]]

“Grande école” (The best of schools, 1995) by Jean-Marie Besset (1959-?), written in a more traditionally realist style, concerns student interactions at a prestigious school of commerce.

==&quot;The best of schools&quot;==

[[File:Escp-Paris.jpg|thumb|Superior School of Commerce, Paris]]

Time: 1990s. Place: Paris, France.

Text at ?

Late at night, Agnes prepares tea for herself as Paul joins her. She suspects that Bernard, Louis-Arnault, and Vieux, roommates of his, conspired to leave the apartment during the week-end so that he could get her to bed. In particular, she guesses that Louis-Arnault suggested that he call her up. She proposes a deal: which among the two will first be able to seduce Louis-Arnault? If she wins, she and Paul will live together in their own apartment; if he wins, she will leave him. Later, while Agnes and her friend, Emeline, await the arrival of the male students, they argue over the interpretation of a current event regarding murder. Emeline leaves as, laden with a heavy package, Bernard steps in to explain that Louis-Arnault lags behind because he is jogging. To their horror, Louis-Arnault enters with his side covered with blood. Paul joins the two in helping their friend head for the hospital. While Bernard and Paul study, the former is unable to concentrate and leaves the room because the latter can only philosophize about what happened to Louis-Arnault. When the latter enters in his bath-robe in a fevered state, he, too, dismisses Paul’s thoughts as devoid of originality. Nevertheless, Louis-Arnault attempts to help Paul in his school-work. “What would really help me,” Paul says, “is that you handle the case and that you put my name on it,” to his friend a bewildering idea. At 3 AM, Louis-Arnault is startled to see Agnes enter their apartment, the door being carelessly left unlocked. Agnes reminds Louis-Arnault of the tender feelings he expressed towards her on his hospital bed and that it was she, not his friend, Emeline, who visited him at the hospital. As they are about to kiss, Emeline startles them by entering from the next room, sleeping there alone as a temporary replacement for Vieux, the absent roommate. “I thought that we had between us a certain form of intimacy,” Emelin declares. “Which does not give you the right to make a scene,” he responds. “Sex binds but does not fixate,” Agnes declares. “I am not talking to you,” Emeline retorts and leaves on seeing Louis-Arnault uninterested in pursuing the discussion. He leaves and then returns with money so that Agnes can head back home, but she declines the offer. He tears up the bills and throws them on the floor. She picks them up. When Bernard returns to the apartment to pick up forgotten lecture notes, he discovers the presence of a stranger, Mecir, Paul’s apparent bedmate. As Mecir leaves to take a shower in their apartment, Louis-Arnault asks Paul whether he will join Agnes to a Saturday night party at her school, having been invited, but Paul is unsure whether he himself is invited. Louis-Arnault suddenly backs off and lifts a chair in self-defense on seeing Mecir come out from the bathroom, for Mecir was the man who stabbed him and now quick to disappear. Later, Emeline informs Paul that Louis-Arnault is leaving his apartment to live somewhere else. When Louis-Arnault shows up to take out his stuff, Paul sarcastically enumerates the advantages of his future business career. Instead of responding, Louis-Arnault heads out to Emeline’s apartment along with her. Agnes tells Paul that she almost consented to sleep with Louis-Arnault; in turn, Paul tells Agnes that he himself succeeded in sleeping with Louis-Arnault. She thinks he may be lying, but,in any event,leaves him.

=Gildas Bourdet=

[[File:Recueil. Photographies. Portraits de Gildas Bourdet. Festival d'Avignon. 1983 - Fernand Michaud - btv1b531264622 (5 of 8).jpg|thumb|Bourdet disclosed troubles arising in an unserviceable service station. Photographs of the author, 1983]]

Still in the realist style, Gildas Bourdet (1947-?) wrote “Une station service” (A service station, 1985). Bourdet also wrote “The spitting of the moon” (1986). Like Behan’s The Hostage, the action takes place in a brothel-bar with a conservative owner, a soldier, and two homosexuals. Réglo, a pimp, threatens to send his whore surnamed Princess to an even worse place and as a result she tries to kill herself by slitting her wrists. A soldier worried about missing a train-boat connection to head overseas with his squad, a failed rock artist, Banana, who comments in a detached way on the action, a rich and crazed trouble-maker, The Belch, who challenges everyone, and a whore protected by a separate pimp, Paquita, form part of the unsavory lot. Unlike the general late 20th century vogue of presenting realistic dialogue in a non-realistic play structure where, for example, characters speak directly to the audience, Bourdet presents realistic dialogue in a realistic play structure.  

== “A service station”==

[[File:Closed Gas Station - panoramio.jpg|thumb|Madeleine wants to sell her poorly attended service station, but is distracted by her husband’s return after an 18-year absence]]

Time: 1980s. Place: Near an airport, France.

Text at ?

At a service station on a road recently blocked, a garage mechanic, Samson, repairs a Peuguot car while Tut-Tut, the mentally defective teenage son of Theresa, a schoolteacher  and eldest of Madeleine’s three daughters, is urinating in the corner. Unfortunately, the stream reaches Samson lying under the car. A biker, Winnock, expects Doris, the youngest among the daughters, to accompany him outside of France, but being under age, she needs her mother’s consent. With 15 days till examination time, she is unwilling even to ask her. A stranger to Samson next appears for permission to use the telephone, a man named Humbert, who wishes to speak to Madeleine, his wife, owner of the gas station, rather than show up barefaced after abandoning her 18 years ago, explaining to her that he has one month to live with a cancerous growth in his lungs and therefore wishes to settle their finances before his death. In the meantime, Madeleine’s second daughter, Maud, once divorced, discusses marriage plans with her fiancé, Thomas, a medical student, yet immediately after he leaves, she calls up another man for a secret rendez-vous. Maud and Doris meet their father, who repeats that he came back to avoid legal difficulties after his death. To Maud and Theresa, Humbert specifies that he left home to become a painter, now possessing 100 potentially valuable paintings to bequeath. While he is alive, Madeleine is unable to sell the gas station without his consent. With nowhere else to go, he heads for Tut-Tut’s cabin in the woods. The next morning, Maud wakes up next to her lover, Richard, inside the Peugeot car, no one noticing except Samson, who sarcastically hangs her panties and hose on the car’s antenna. Doris informs her mother that she wants to leave home before Maud’s wedding. After a night in the forest, Humbert adds another reason to explain his absence, the discovery 18 years ago of his wife’s letters from her adulterous lover. Surprised but remorseless, she repulses his wish to stay at her place until his death. Winnock returns irate because Doris failed to show up at their proposed meeting place, though gladly holding her father’s written consent, enabling them to leave for a rock concert at San Sebastian, Spain. However, Madeline declines to give hers until Doris obtains her high school diploma. Richard comes back to recover his missing wallet and knife, left in the car. Unaware that the man is her sister’s lover, Theresa hops into his car to buy her sister’s wedding present. The night before their wedding day, Thomas comments favorably on Maud’s wedding dress, but once again as soon as he leaves, she calls up Richard, only she can only reach his answering machine. “It’s me again,” she says on the phone. “I long for you, for us. I need you, we must see each other.” She is startled when he suddenly shows up with news of his intention to join a friend, owner of a video store in Tahiti. Nevertheless, he still wants her, and, after some hesitation, so does she, until Pinnock interrupts their tête-à-tête, ready to head towards Spain. But, surprised to see Richard, whom she saw a while ago in Theresa’s company, now in Maud’s, Doris has no wish to follow Pinnock at the moment. Maud worries about what Richard was doing with Theresa. As a result, she drinks pastis in excessive amounts, then wobbles off into the woods to see her father. In the meantime, Samson has repaired the car. On the wedding day, Thomas is distressed to find only Richard on the premises, Theresa’s invited guest, as well as a large number of abstract paintings hung on the walls throughout the place. Thomas recognizes Richard’s car as the one that recklessly shot in front of his a few days ago. Fifteen minutes late, the entire family shows up to head for city hall, except that Maud’s wedding dress is torn and dirty and Humbert’s clothes are muddied from lying in the woods. Exasperated, Thomas grabs Maud, at which she calls Richard for help. When Thomas wonders why she would call a wedding guest for help, she blurts out that Richard has been her lover for a few months, at which Theresa is stunned. Threatened by Thomas, Richard takes out his knife, Thomas a drive shaft while an overexcited Tut-Tut pours petrol over Richard and Madeleine takes out a lighter to stop the fight. Disgusted over the entire situation, Thomas throws his ring at Maud’s feet and leaves. Intending to close up shop, Madeleine offers Samson the Peugeot, but he needs to think it over before accepting. Richard leaves open the possibility of Maud joining him. Theresa considers that comment indelicate towards her, but yet finds the man irresistible while Doris is still uncertain about whether to follow Pinnock.  

{{BookCat}}</text>
      <sha1>eaifr1chm366zmxydfryhbhnfqj2x1t</sha1>
    </revision>
  </page>
  <page>
    <title>History of Western Theatre: 17th Century to Now/German Realist</title>
    <ns>0</ns>
    <id>242738</id>
    <revision>
      <id>4657101</id>
      <parentid>4629226</parentid>
      <timestamp>2026-08-10T20:21:11Z</timestamp>
      <contributor>
        <username>Neojacob</username>
        <id>363908</id>
      </contributor>
      <comment>/* Frank Wedekind */ typo</comment>
      <origin>4657101</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="109641" sha1="mlkmmujl0b5sbuszpabx15hlngfvj9m" xml:space="preserve">Realism and Naturalism developed in Germany in parallel to developments in Scandinavia. &quot;Realism was content to observe; naturalism demanded scientific experimentation&quot; (Henderson, 1914 p 115). Witkowski (1909) described the essence of naturalism as follows: &quot;Naturalism chooses its material exclusively from the life of the present day and preferably from the domain of the lowly, the ugly and the morally objectionable, which up to the present has been excluded from artistic treatment. Instead of plots it offers accurately observed scenes and individual incidents which are to be considered typical of the conditions of society. In addition, abnormal morbid qualities are assigned to the characters introduced which, however, likewise claim a typical significance as the results of the unnatural conditions of modern life. Everything is derived from mythological and pathological causes. The law of causality holds unconditional sway, represented by scientific hypotheses, such as heredity and the influence of suggestion upon the will and by socialistic theories. Instead of strong utterances of passion, conversation alone serves as the means of sketching character and of disclosing the progress of events. Involuntary suggestions, instead of intentional communications, seeming equalization of what is essential and non-essential, avoidance of the monologue and of everything serving merely for the enlightenment of the spectator, and the most accurate prescriptions for everything external are to produce complete illusion without any assistance from the imagination of the spectator. The single aim is ostensibly to do battle against lying, hypocrisy and whatever is antiquated in art and life. At the same time, judgment is mostly given from the standpoint of youthful inexperience and of extreme political and social endeavor which would like at one stroke to put a new order of society and a new art in the place of the old, and to which therefore everything is welcome which makes light of prevailing views&quot; (pp 146-147). 

Clark (1915b) described the realist/naturalist movement as follows: &quot;The Naturalist movement in literature, in which Tolstoy, Zola, Ibsen, and Strindberg were the leaders, bore fruit in France with the Theatre Libre, founded by Andre Antoine in 1887, and in the German theater abovementioned. The new movement aimed at two things: the delineation of character in as truthful a manner as possible, and the presentation of problems and theses directly affecting the society of the day. These ideas were by no means new, but the combination of greater adherence to external details- usually 'unpleasant' and often brutally shocking- and purposefulness was decidedly novel, [including the unemphatic ending], quite a common practice nowadays, and the reason for it is chiefly that it heightens the illusion. In life, the exciting is mingled with the commonplace, and one of the most interesting and dramatic things in life is the strange contrast between the sublime and the commonplace, between the tragic and the comic. Therefore, in place of ending his act or his play with a scene of great tension or high emotion, the dramatist seeks to reproduce parts of life, makes a still more lifelike and exciting scene, and places one of these contrasted moments at one of the most critical points of his act or play: the last&quot; (pp 107-134). 

=Gerhart Hauptmann=

[[File:Gerhart.Hauptmann.jpg|thumb|Gerhart Hauptmann was the dominant dramatist of late 19th century German theater]]

Among major figures of late 19th century drama, Gerhart Hauptmann (1862-1946) stands out for the gritty proletarian play, &quot;Die Weber&quot; (The weavers, 1892) and the criticism of the judicial system inherent in &quot;Der Biberpelz&quot; (The beaver coat, 1893).

“Applying the tenets of naturalism and the weavers uprising of 1844, Hauptmann forged an historically accurate document of extraordinary power...In The Weavers, Hauptmann stripped poverty of its hitherto sentimental and romantic aspects...The forces of reaction, embodied in religion and the state, aid Dreissinger in his battle with the weavers. Pastor Kittelhaus and the police chief resort to pietistic nonsense and brutal force to assuage the weavers...Hauptmann was the first to introduce the proletariat as protagonist and to treat a revolutionary theme realistically” (Grace, 1973 pp 190-191). &quot;The weavers&quot; &quot;is the story of a strike, accompanied by tumult and riot, which is soon put down by military force. From beginning to end it is full of destruction and human misery, but the plot is developed with consummate skill and art&quot; (Moore, 1900 p 221). “The protagonist of the play is a whole class, the weavers...Because Hilse is old...it is easier for him to accept suffering as his lot [than his granddaughter]. Unlike his daughter-in-law, Luise, who is concerned about the fate of her still unborn children, old Hilse does not look into the future” (Michaels, 1986c pp 871-873). The play &quot;consists of successive pictures and situations, and yet it is an inseparable unity and entity, by reason of the atmosphere which pervades it from beginning to end&quot; (Holl, 1913. p 29). &quot;There is no construction in the accepted sense: the play consists of a series of pictures of abject misery. Naturalism has here an interesting development: there is no individual hero, but the weavers collectively are the hero, each individually insignificant, but as a mass a sweeping force. Die Weber is the first play in which mass psychology is successfully handled; here the mass does indeed express itself as a unity; all the individualities coalesce in an entity&quot; (Bithell, 1959 p 18). In The Weavers, Hauptmann “created practically a new species of dramatic art...The different characters have each something distinct and individual, some of them we meet in all five acts, but while in one they are central figures, in the others they are pushed into the background” (Wiehr, 1972). “The greatness of Hauptmann’s art of characterization is revealed in the way he lets us see in the crowd of rioting weavers the physiognomies of the individuals of whom it is formed” (Behl 1972). &quot;Its hero is the wretched, down-trodden weaver-population; its all-compelling fate, starvation. One picture of misery follows another in quick succession; dozens of types of decay drawn with marvelous truthfulness. All grades of generations and view-points, from the paltry remainders of a better past to the youngest, saddest mar- tyrs of the desperate present. All resembling one another in their humbleness, their weakness, their patience, their longing. The most industrious, loyal, innocent people drained to the last drop by the vampire of capitalism. State and church, in Mammon^s service, conspiring against the poorest of the poor. Nobles, citizens, peasants, their oppressors or exploiters. A small number of intelligent sympathizers...In spite of the great complexity of the scenic events there is no relaxation of the dramatic tension&quot; (Lessing, 1912 pp 94-95). The play &quot;represents what early naturalism had set as its goal. In rapid succession act follows upon act, each one presenting minutely detailed characterizations that are skillfully integrated to achieve a tremendous effect. In the presentation of the weavers' graphic suffering before our eyes, there is no theoretical discussion of social maladjustment...Individual characters are pictured that represent different classes, different ages, and both sexes, all suffering in an environment which is so closely bound up with their misery. But the tragedy of the individual assumes a new significance and is again reflected in the tragedy of the mass. Hauptmann's subjective reaction to this theme and his historical treatment of the material combined to make a drama free from tendency and propaganda that will continue to stand as a great human document&quot; (Reichart, 1932, p 211). “The Weavers resists portraying the proletariat as a unified collective that understands its common struggle, and it does so precisely through the weavers’ divergent attitudes toward their work. A few individual characters stand out from the very beginning, such as the bold and rebellious Bäcker and reserve soldier Moritz Jäger, whose military service has ren- dered him worldlier than his poor folk. These two stir the young weavers to destroy the new power looms and the millowners’ houses, ‘hack[ing] at the beautiful furniture as if they were working for wages’. Bäcker and Jäger are no leaders, however, as they do not know where or how to direct the revolt beyond causing more wreckage. Characters that refuse to join the riot, such as Old Hilse, further undermine the idea of the weavers’ being a homogeneous community” (Zhulina, 2024 p 184). “There is whispering and grumbling at the end of [act 1], but there are no plans, no thoughts of action; there is no beginning of a plot. Nor does the second act bring any definite resolve...But the third act brings the despair and the unrest to the breaking point...The ensuing tumult is well under way when the fourth act begins...Only when we have begun to understand the roles played by the numerous characters, to feel the cumulative effects of the concrete pictures and incidents, to experience the growth of the bewilderment and despair and exaltation which sweep the weavers to unpremeditated action can we begin to appreciate what Hauptmann has accomplished” (Sinden, 1957 pp 55-58). The play “is a genuine working class drama. For once a naturalist dramatist goes beyond the fairly narrow limits of most of the works...which tend to treat social or ethical problems from a bourgeois intellectual standpoint and in a bourgeois setting...Here naturalism does not mean a lack of purpose or structure...The release of anarchic, animal fury, which amazes some of the weavers themselves, is explained quite fully and quite naturally...The revolt is a despairing outcry, or, as old Baumert puts it, a chance to get a breath of fresh air. The weavers do not seriously expect it to bring about any permanent improvement in their conditions...Superficially, Hilse is distinguished from his fellow-weavers by his firm adherence to his religious beliefs, but...his Christianity is as much a religion of vengeance as forgiveness...This attitude...is just as much a cry of hatred as the inarticulate fury of the other weavers” (Osborne, 1998 pp 137-146). &quot;The weavers&quot; has been described as &quot;a saddening, humiliating, reproachful picture of hopeless poverty...To look at the wretched people crowded into the outer office of Dreissiger's factory, one would never suppose them capable of such sturdy violence as subsequently animates them. Deathly pale men, women, and children: hollow-eyed, stoop-shouldered, tottering as they move. They fairly sneak to the cashier's desk to receive the few pennies due them for their week's work, each drawing himself together as if conscious that he really has no place on earth and is suffered to remain only in consideration of contracting himself into the smallest possible compass&quot; (Nirdlinger, 1899, pp 199-201). What many critics emphasize is the presentation of a group as the main character. &quot;The strike is the only character of importance; men and women appear and disappear only that the strike may be presented to us&quot; (Hale, 1905 p 40). &quot;Hauptmann created a timeless work. Radicals may complain, as they do, that the play does not outline an acceptable course of action, and their opponents may dislike its painful picture or its social implications. But The Weavers lives by its vivid evocation of realities and by its tight-lipped compassion. The most vigorous tendencies of the age were welded into drama when Hauptmann combined naturalist observation with social-democratic sympathies in this history of the revolt of the Silesian weavers in 1844...The Weavers was epoch-making. Never before had naturalism been linked so plainly with direct social issues, and with this drama Hauptmann cemented a new bond between the realistic theatre and the masses&quot; (Gassner, 1954a pp 454-456). &quot;Earlier dramatists had never tried to sketch any but individual natures. When it had been a question of using the masses in a drama as co-acting factors, then either individual representatives would be picked out, as in Shakespeare's 'Julius Caesar' (1599) or Goethe's 'Egmont' (1788), and treated according to the principles of individual psychology, or the chorus of Greek tragedy gave the model and the feeling of unity was indicated, as in that by some few general human impulses which are present in all. Beginnings of a 'psychology of the masses' are to be discerned in Kleist's 'Robert Guiscuard' (uncompleted), in Hebbel's 'Judith' (1841), and in Ludwig's 'The Maccabees' (1852). Here is already shown something of that immense strengthening force which every impulse receives because of a number feeling it in common, of those sudden transitions which arise therefrom and of the blind passion of the excited popular mind, which is swayed by quite different laws than affect the individual. But still no one before Hauptmann had attempted to make this knowledge fruitful to the drama. In Schiller's 'William Tell' (1804), the people spoke and acted just as every Swiss would have spoken and acted for himself. In The Weavers, on the other hand, the representatives of the class described there form a harp, all the strings of which begin to give out at the same time, when the air-waves strike them, low complaining or loud screaming notes, so that the individual voices together form a mighty accord, in which the peculiar quality of each is indeed discernible, but none prevails over and sounds above the other&quot; (Witkowski, 1909 pp 194-195). The play “simply presents a strike, makes it live before us, shows us the misery that occasions it, and the misery it occasions; it leaves us profoundly convinced of the solidarity of society, and the need that our conscience should correspond to our consciousness of that fact…What impresses one chiefly however is that in this piece we are not dealing with the individuals so vividly presented, as much as with masses of individuals. The interest inheres in the cause, not in particular cases. The catastrophe does not involve any main promoter of the movement so far as the spectator sees, but only an innocent, great-hearted protestor. The movement then is the hero ; it has many and various representatives, and when we have heard and seen the play, the actual human world has been before us in process of evolution, an evolution in which individuals are sacrificed to the clearer manifestation of the type” (Guthrie, 1895 p 287).  &quot;Hauptmann may be said to have created a new form of drama in The Weavers, and that form is what may be designated as the tableau series form, with no hero but a community. As the play is not a close-knit entity, the first act is casual, and might open at almost any point; and since it starts with a picture, or part of a picture, there is hardly anything to be known of the past. The result is that no exposition is needed. The audience sees a state of affairs, it does not lend its attention and interest to a story or the beginning of a plot or intrigue. This first act merely establishes the relation between the weavers and the manufacturers. There is no direct hint given in the first act as to what is to come in the second; the first is a play in itself, a situation which does not necessarily have to be developed. It does, however, prepare for the revolt, by showing the discontent among the downtrodden people, and it also enlists the sympathy of the audience. Act two is another picture, this time that of the homes of the weavers; the effect produced is one of blackest misery and unrelieved poverty. Two points should be noticed: first, the dramatist develops some characters, like Mother Baumert and Ansorge, but only to a certain extent, for fear of their overshadowing the chief business of the play, which is the presentation in concrete form of the oppression and struggles of the weavers; and second, the plot- such as it is- is started by Jaeger. But this plot is not permitted to absorb the interest of the audience, it is rather brought in almost as an incident, and does not attain to great proportions until a large number of the weavers participate, later on. And when that happens, the plot and characters have an equal claim upon our attention. This act does look forward; it throws out tentacles of interest, for when Ansorge says: 'We'll stand it no longer, we'll stand it no longer come what may,' the audience knows that trouble is ahead, and wants to see its result. The third act carries the plot forward, and gives a further picture of the life of the weavers, this time a little less sordid than in the foregoing acts. The change of scene is made primarily in order to give variety to the whole picture, and also to furnish a likely gathering place for the instigators of the rebellion. The end of the act brings the plot to a higher degree of development, and increases the suspense; Hornig's words,'It'll not surprise me if this ends badly,' are clearly prophetic, and prepare for the next act. Between the third and fourth acts the rebellion has come to a head, and the weavers start on their warpath of depredation. The contrast in setting is again good; this time we are in the luxuriously furnished home of the capitalist. We are aware of the presence of the wild crowd outside, and know that the revolt is making quick headway. The entrance of Jaeger as a prisoner, his subsequent release by the mob, the evacuation of the house by its owners, the entrance of the weavers, the despoiling of the rich furnishings, all supply excellent dramatic action. By the end of the act, the weavers are like wild animals, whom nothing can curb. Here, then, is the culmination of the action: the climax. What more is expected? Clearly, the result of what has happened. Will the weavers conquer? The last act must terminate the rebellion, but the mere ending, in the defeat of the strikers, is not sufficient to fill an entire act; there must be something further. Hauptmann has therefore introduced an incident that will supply the need. The reactionary weaver is accidentally shot. The purpose of this is doubtless to drive home the irony of fate, in this case the uselessness of revolt. This bit of action is very skilfully interwoven, and leaves us with a keen appreciation of the wrongs of the weavers, by reason of its vividness- also because it is the last incident of the play. While it is true that we sympathize with the weavers as a class up to the last act, we lack the personal element. For example, we may read in a newspaper that five thousand people die of the famine, but until we see the mother dying in an effort to feed her child, or the father killing his family outright rather than see them starve- until we see these things individually- they will not touch us&quot; (Clark, 1915b pp 90-93). Goldman (1914) remarked on the Baumert incidents that &quot;appalling as the scene in the office of Dreissiger is, the life in the home of the old weaver Baumert is even more terrible. His decrepit old wife, his idiotic son August, who still has to wind spools, his two daughters weaving their youth and bloom into the cloth, and Ansorge, the broken remnant of a heroic type of man, bent over his baskets, all live in cramped quarters lit up only by two small windows. They are waiting anxiously for the few pence old Baumert is to bring, that they may indulge in a long-missed meal...It did not do old Baumert much good. His stomach, tortured and abused so long, rebelled, and the old man had to 'give up the precious dog'...Man's endurance is almost limitless. Almost, yet not quite. For there comes a time when the Baumerts, even like their stomachs, rise in rebellion, when they hurl themselves, even though in blind fury, against the pillars of their prison house&quot; (pp 102-103). From the early 20th century viewpoint described by Wilson (1937),&quot;the weavers have no minimum wage, no trade union, no proper regulation of hours. They bring the cloth from their homes to the factory and are entirely at the mercy of the owners. They are bullied and cheated. A girl faints from hunger. A man kills his dog for food. At length the workers rebel against their inhuman treatment. They break into a revolutionary song, march off to their employer’s house and sack it. Police and soldiers are summoned. There is some spasmodic shooting in which a weaver, who has doggedly remained at work, is killed. Nothing is achieved. There is no neat ending, no suggestion of reform: nothing but a vivid picture of things as they are, or, at least, as Hauptmaim saw them, for he made no attempt, as Galsworthy did in Strife, to be impartial&quot; (pp 176-177). &quot;A tag that persists in the recollection over many years is the fiendishly mordant last line of Hauptmann’s famous labor drama, The Weavers. The starving workers finally revolt against their tyrannical oppressor, pillage his premises, are driven back, and the one old weaver who still steadfastly believes in the old order and refuses to leave his loom is shot down. His little granddaughter rushes into the room, grows frightened, notices that something has happened, puts her finger in her mouth, goes cautiously up to the dead man, and calls his name. Her aged grandmother, the weaver’s wife, edges to her side, looks at old Hilse lying there, and speaks to him: 'Come, husband, say something; you look as though you were afraid.' In that single word 'afraid', there is more ironic poison than in all the other capital-and-labor dramas combined&quot; (Nathan, 1943 pp 177-178). &quot;The two principal qualities which are the sources of Hauptmann's art and its form are sympathy and longing. Because of these qualities, he is one of the most typical representatives of his day, not only for Germany, but for the whole of Europe, but not one of its masters. These two qualities are of a negative nature, for even the wrath that arises out of pity can only give itself expression in destruction- as in Die Weber, for instance. There is no building-up power in them. Herein lies the great difference between European and American feeling: where the European is filled with longings and with the consciousness that they will never be fulfilled, the American is carried away with the enthusiasm which leads to action&quot; (Freund, 1912 p 128).  

The Beaver Coat &quot;has a certain similarity to Kleist’s The Broken Jug; in both comedies there is a culprit whose transgressions are investigated in court but whereas in The Broken Jug the culprit is the investigating judge himself whose cross-examination of innocent parties unravels his own guilt, in The Beaver Coat the judge is a pompous fool who is led by the nose by the culprit, the egregious washerwoman Frau Wolffen. This lady, unshakable in her brazen effrontery, gets the court bailiff to hold a lantern while she steals wood; to the judge she is the pattern of honesty” (Bithell, 1959 p 29). “Every thread of the play is gathered into the moments of the fourth act which form its climax. True, there is no single knot and there is no resolution: Frau Wolff is not caught and von Wehrhahn is not dismissed...What [Hauptmann] saw was a comedy of cross-purposes, of an aristocratic and reactionary bureaucracy fighting in the dark” (Sinden, 1957 pp 156-157). Hauptmann &quot;wrote a thieves' comedy which grouped a series of capitally drawn figures about two types of the present day. The washerwoman, Mother Wolffen, is a masterpiece of accurate conception of a lowly soul with her shrewd impudence, her pliant loyalty and her unscrupulous use of all possible advantages. She is always pretending to be simple, and in this way comes out on top while her opponent, Superintendent Wehrhahn, inevitably falls into her nets because he wants to appear sharper than he is and is blinded by the arrogance of infallibility. The plot of The Beaver Coat is a little meagre and suffers from the repetition of the theft. To this the author was seduced by the desire to have the incident serve as a type&quot; (Witkowski, 1909 p 198). &quot;The contrast of bare reality with the presumptuous honesty of the heroine of the play, the washerwoman, Mrs Wolff, produces the most comic effect. Hauptmann realizes that the field of the comic is the intellect, and he contrives to raise the aspect of all actions to this level, in order to prevent any ethical and moral ill-feeling from damaging its humour. He therefore chooses an old literary device- a scene in court- to form the setting of a comedy. The contrast of the blind and pretentious judge with the clever washerwoman who is the moving spirit in everything and pretends to know nothing, is perfect comedy. All thefts, at first the wood- the policeman unwittingly assisting the thief—then the fur coat, are committed by Mrs Wolff, and yet the honest soul is never suspected. It is a scene of thrilling humour, when we see together in court the judge, the thief, the owner of the stolen goods, its receiver, the wrongly suspected, and the thief, Mrs Wolff, the only calm one of the lot, domineering by her acknowledged respectability&quot; (Holl, 1913 pp 36-37). Hauptmann's &quot;thieving washerwoman Mrs Wolff, who is the wife of a poacher, is a magnificent character, and the impudence with which she hoodwinks the bewhiskered police-superintendent Werhahn after she has stolen a beaver coat is conducive to rich earthy laughter. Werhahn is a perfect caricature of an officious incompetent, and much irony is achieved when this Dogberry who suspects a red network in every corner proclaims the amoral Mrs Wolff the most upright woman in the village. She takes the compliment gracefully and improves upon it by declaring that the place is becoming positively too immoral for her!&quot; (Gassner, 1954a p 458). The Beaver Coat “is a celebration of the individual and a light-hearted send-up of the restrictions and regulations people have to put up with, which are at one and the same time social necessities and symbolic of the impersonal system against which the individual has to pit his wits” (Skrine, 1989 p 55).

“The new form of drama created by Gerhart Hauptmann we shall denominate the drama of pure naturalism. In such dramas, the subjects are invariably chosen from contemporary life and, because of the sharp contrasts and new materials afforded, from those phases of life which had hitherto been rigorously excluded from the domain of the drama- the life of the humble and the lowly. The subjects treated were repulsive to many theater-goers, accustomed to the universal idealization of life in the conventional theater. The ugly, the abnormal, the asymmetric were types enthusiastically studied by the naturalists. Their search was not for beauty, for the ideal, or for the moral; their search was only for the truth in the light of modern social relativity. A graphic and faithful projection of a section of human actuality- that, in fine, was the ideal of the naturalist” (Henderson, 1914 pp 123-124). In Hauptmann's works, &quot;the delineation of all these characters has two constant qualities: objectivity and justice. The author has not merged the sharp outlines of humanity into the background of his own idiosyncrasy. These men and women are themselves. No trick of speech, no lurking similarity of thought, unites them to each other or to the mind that shaped them. The nearer any two of them tend to approach a recognisable type, the more magnificently is the individuality of each vindicated&quot; (Lewisohn, 1915 pp 123-124).

==&quot;The weavers&quot;== 

[[File:Die_Weber_1897_by_Emil_Orlik.jpeg|thumb|1897 Color lithographic poster of &quot;The weavers&quot;  by Emil Orlik (1870-1932)]]

Time: 1840s. Place: Silesia, Germany.

Text at http://www.gutenberg.org/ebooks/9971 https://archive.org/details/in.ernet.dli.2015.151773/page/n13

In Dreissiger's shop of fustian-weavers, the manager, Pfeifer, hears several complaints. The workers want to be paid in advance. &quot;People who are industrious, and understand their work, and do it in the fear of God, never need their pay in advance,&quot; Pfeifer retorts. What about bad pay for bad work? &quot;If you want to live well, then be sure to weave well,&quot; answers Pfeifer. They face more problems; they are underfed. One boy in the shop faints from hunger. To get meat, Baumert had to kill his dog. For complaining too loudly, Becker is dismissed. When one of her neighbors asks for food, Mother Baumert answers: &quot;There's not so much as a handful o'salt in the house, not a bite o' bread, nor a bit o' wood for the fire...The best thing as could happen to the likes o' us, Jenny, would be if God had pity on us an' took us away out o' this weary world.&quot; Because of her mother's rheumatic pains, Bertha says: &quot;We've to dress her in the mornin' an' undress her at night, an' to feed her like a baby.&quot; Says the mother about the women workers: &quot;Their feet never off the treadle from year's end to year's end...An' with it all they can't scrape together as much as'll buy them clothes that they can let theirselves be seen in; never a step can they go to church, to hear a word o' comfort.&quot; Although the oven smokes in their house, Baumert knows that it is useless to complain to the cottager, Ansorge. &quot;One word of a complaint an' out we go. He's had no rent from us this last half-year,&quot; he says. When an old friend, Jaeger, now a soldier, drops by with a roast for him, Baumbert is unable to hold it in. He vomits and cries in rage. &quot;We don't need no meat.&quot; Jaeger then comments sarcastically. &quot;The manufacturers eats it for us.&quot; &quot;Things was different in my young days,&quot; Ansorge reminisces. &quot;Then the manufacturers let the weaver have his share. Now they keeps everything to theirselves. An' would you like to know what's at the bottom of it all? It's that the fine folks nowadays believes neither in God nor devil.&quot; In the common-room of a public-house, expensive funerals are spoken of, the pastor all the more profiting by large ones. Says Hornig, the rag-seller, to Wiegand, the joiner: &quot;When you see the rows o' little children's graves, you pats yourself on the belly and says you: this has been a good year; the little brats have fallen like cockchafers off the trees.&quot; One day, Jaeger and Becker enter the shop arm in arm, singing. &quot;They're goin' to Dreissiger's to make him add something on to the pay,&quot; explains Baumert to the rest. In Dressiger's private room, Pastor Kittelhaus is disturbed at hearing strains of the &quot;Weavers' Song&quot;. For his complaints, Jaeger is arrested. On his side, Dreissiger also complains of the present times. &quot;Most certainly that is what they used to be- patient, easily managed, well-behaved and orderly people.&quot; he says. &quot;They were that as long as these so-called humanitarians let them alone. But for ever so long now they've had the awful misery of their condition held up to them.&quot; At the sight of Jaeger tied up as a prisoner, the crowd becomes rowdy and free him. &quot;They've set Moritz Jaeger free- they've thrashed the superintendent and driven him away- they've thrashed the policeman and sent him off too- without his helmet ...his sword broken...Oh dear, oh dear!&quot; exclaims Pfeifer in a panic. An old soldier with a lost arm, Hilse, weaving in his own workroom, disagrees with this uprising &quot;If we've no butter, we can eat dry bread- when we've no bread, we can eat potatoes- when there's no potatoes left, we can eat bran,&quot; he declares. Hornig reports the damage caused by the workers at Dreissiger's home: &quot;They've wrecked his house from the cellar to the roof,&quot; he says. But this situation does not worry Schmidt, the surgeon. &quot;The troops will be on them in no time,&quot; he says with confidence. Hilse's son-in-law, Gottlieb, is glad at least of what the workers have gained. &quot;We're to have our half-pound o' meat on Sundays, and now and again on a holiday sausage with our cabbage. Yes, things is to be quite different, by what he tells me.&quot; Yet Hilse maintains his point of view. &quot;They've let themselves be tempted by Satan, an' it's his works they're doin',&quot; he grumbles. In contrast, Luise, his daughter, joins the rioting weavers. &quot;How many hundred nights has I lain an' racked my head to think what I could do to cheat the churchyard of my little one? What harm has a baby like that done that it must come to such a miserable end- eh? An' over there at Dittrich's they're bathed in wine an' washed in milk,&quot; she says. When police officers shoot at the workers, a stray bullet strikes Hilse in his own house. His blind wife does not understand why he is so silent, crying out in distress: &quot;Come now, father, can't you say something? You're frightenin' me.&quot;

==&quot;The beaver coat&quot;==

[[File:Max_Pallenberg_und_Else_Lehmann_im_%27Biberpelz%27.jpg|thumb|Krueger, played by Max Pallenberg (1877-1934), is manipulated by Mrs Wolff, played by Else Lehmann (1866-1940), at the Deutsches Theater directed by Max Reinhardt, 1919]]

Time: 1890s. Place: Berlin region, Germany.

Text at http://www.gutenberg.org/ebooks/9971

Adelaide has some town news to relate to her mother, Mrs Wolff, a washerwoman in the employ of the Kruegers. &quot;Mrs. Krueger has bought a fur-coat that cost pretty near a hundred crowns. It's a beaver coat,&quot; she specifies. When Mr and Mrs Motes arrive to settle their account, Mrs Wolff clears away anything that could in any degree suggest that her husband, Julius, a carpenter, had just poached a stag. Mrs Motes shows her several wire-snares they have found, evidence of poaching. Mr Motes was once a forester, but was shot in the eye and is now a free-lance writer. &quot;Forester Seidel has nabbed a poacher again,&quot; he relates. &quot;He'll be taken to the detention prison tomorrow. There's an officer with style about him! If I hadn't had my misfortune, I could have been a head forester today. I'd go after those dogs even more energetically.&quot; Mrs Motes pretends to laugh off a rumor that they were once forced to move away from the Krueger premises, at which her husband's face reddens in rage: &quot;The reason why I moved away from that place? You'll find it out some day. The man is a usurer and a cutthroat,&quot; he avers. After they leave, Mrs Wolff has an idea for her husband concerning what they might do to the Kruegers where their other daughter, Leontine, works as a servant. &quot;An' if I was to say: all right, you abuse my children, I'll take your wood- a nice face you'd make,&quot; she says. &quot;I wouldn't do no such thing...I don't give a--! I c'n do more'n eat, too. I'd like to see! I wouldn't stand for nothin' like that. Beatin'!&quot; he responds. Instead of that plan, he goes out to steal the wood himself as Constable Mitteldorf arrives complaining that his superior, Justice of the Peace Wehrhahn, has formed an unfavorable opinion about his work: not severe enough. &quot;I ain't keen enough after the people,&quot; he says. Meanwhile, Motes reports to Wehrhahn the liberal opinions expressed by Krueger concerning his boarder, Dr Fleischer. Wehrhahn hates such people. &quot;Under the protection of my honourable predecessor, the sphere of our activity has become a receptacle for refuse of various kinds: lives that cannot bear the light- outlawed individuals, enemies of royalty and of the realm. These people must be made to suffer,&quot; the judge declares. Motes hands the snares over to the judge, then Krueger arrives to declare that his wood was stolen in front of his garden after his servant, Lenontine, refused to take it in. &quot;And when I insisted on her doing it, she ended by running away. I intend to bring suit against her parents. I intend to claim full damages,&quot; he announces. When Mrs Wolff is called in and asked about Leontine's behavior, she complains about her daughter being forced to carry so heavy a load so late in the evening. She refuses to pay for Krueger's wood and quits her job as his washerwoman. Back at home, Adelaide tells her mother she has discovered where the new wood comes from, at which the mother cuffs her head. Fleischer reports to Mrs Wolff that Mrs Krueger's beaver coat has been stolen and that the new washerwoman has been fired because of it. As Fleischer leaves her house, Krueger arrives. Mrs Wolff tries to hide the stolen wood, but he fails to notice it as his. He wants to forget their difference by hiring her back along with Leonine, to which she agrees. Called again at court, Mrs Wolff warns the boatman, Wulkow, that he should not be seen wearing his beaver coat, the one she stole and sold to him. She brings to Wehrhahn's attention that Adelaide found a green waist-coat that belongs to Krueger. Fleischer then enters to report he saw a slovenly boatman at a distance suspiciously wearing a new beaver coat. Hating the sight of the liberal, Wehrhahn takes no notice of his report. Krueger then arrives to complain that the judge takes no interest of the robberies, presenting Mrs Wolf, Fleischer, and Wulkow as cases in point. In regard to a boatman with beaver coats, Wulkow declares: &quot;There ain't nothin' suspicious about that, your honor. There's many as has fine coats. I got one myself, in fac'.&quot; Krueger then accuses Motes of trying to inveigle a woman named Mrs Dreier into committing perjury against Fleischer for insulting the emperor. But the judge's mind is set against Fleischer. While looking approvingly at Mrs Wolff, he declares: &quot;And as surely as it is true when I say: Mrs Wolff is an honest woman; so surely I tell you: this Dr Fleischer of yours, of whom we were speaking, is a thoroughly dangerous person.&quot;

=Arthur Schnitzler=

[[File:Arthur Schnitzler 1900.jpg|thumb|Arthur Schnitzler revealed how one thing leads to another in life's merry-go-round]]

Also of note in the German-speaking drama is the Austrian playwright, Arthur Schnitzler (1862-1931), in particular for &quot;Reigen&quot; (Roundelay, or La ronde, 1897).

Puritan-minded critics found Roundelay “coarse and vulgar...in which love is described with merciless candor and in its ugliest aspects...Despite the author’s terrible pessimism in his attitude to love in this play, there is a trace of the suppressed pathos which has grown into hard cynicism&quot; (Lamm, 1952 pp 135-243). Henderson (1912) was irate over this “most unashamed exposure of the mechanics of eroticism,...a piece of frank naturalism, a vicious circle of adultery..., the last word in cold-blooded suggestiveness” (p 639). &quot;The ten dialogues of Reigen are necessarily indecent, because they are the demonstration of facile coition, such as any physician or court missionary could piece together from experience of human nature- which is literally, at its erotic rawest, as here presented. We go round a lively circle of clasped playlets: in the first street-girl and common soldier have their sordid moment, in the second this soldier and the housemaid, then housemaid and son of the house, and so on till in the tenth dialogue the circle meets with the street girl coupling with a count” (Bithell, 1959 p 232). “A little cleft of puritanism still separates us from the appreciation of Schnitzler’s delightful comedies- and the bridge across is slippery. The strenuously immoral life of the young Viennese dandy, which he satirizes without condemning, seems to us hardly a matter of laughter” (Moderwell, 1972 p 209). “The circularity of the dramaturgy asks questions of a hierarchical society and the sexual mores that underlie it. The play is a remarkable in the way that it contrasts well-observed naturalist dialogue with a series of generic character types, suggesting that the language itself is not individualized but rather a complex social code predicated upon sex” (Barnett, 2008a p 201). 

Roundelay “was the first attempt to put the sexual act on the stage and to illustrate, with bitter irony and sparkling wit, the extent to which the purely physiological side of sex is overshadowed by social ambition, snobbery and the struggle for domination” (Esslin, 1968 p 74). Roundelay was &quot;an erotic counterpart to the medieval dance of death&quot; (Garten, 1964 p 60), a dance of sex, duologues comprising 1) prostitute and soldier, 2) soldier and parlormaid, 3) parlormaid and young gentleman, 4) young gentleman and young lady, 5) young lady and her husband, 6) husband and girl, 7) girl and poet, 8) poet and actress, 9) actress and nobleman, 10) nobleman and prostitute, lovemaking occurring in each. “Perhaps the most cruel thing about the piece is the continued lack of feminine comprehension in this matter, since every one of the ten scenes shows the woman continuing to chatter about heaven to the man entangled in his self-made hell. ”There are five women in Schnitzler’s play, a 'cocotte' [courtesan], a servant-girl, a [wordly woman], a little dressmaker, and an actress, each of whom is seen first with one lover and then with another or her husband. The cocotte meets a sailor, who leaves her for a servant-girl dancing in a cafe. The servant-girl pretends to be seduced by a young man who has an affair with the 'femme du monde' who allows her husband to lecture her on the beauty of faithfulness, after which he deceives her with the little dressmaker. The little dressmaker makes love to a famous dramatist, who has an episode with an actress, who grants favours to a count, who spends a night with the cocotte with whom the play began. And so the chain is complete” (Agate, 1944 p 125).

“With varying degrees of eloquence, in which elements of brutality, sentimentality, lust, and flirtation are combined, the mute sex act is prepared for and concluded...None of the characters is honest, for each one must prevent the new partner in the second scene from learning about the partner in his first scene (even the prostitute tries to create the illusion of exclusivity). Everyone plays the game by dissembling, remonstrating, and expressing seeming reservations, but such protestations are never serious, for they are contradicted by the second scene...Except for sex, there is nothing between the couples...Each character does justice to his profession, for he does not forget his work or his responsibilities because of the encounter. The husband never forgets his business dealings, the poet never forgets his writing, the actress never forgets her roles, and the wife is mindful of her obligation to have children...’Hands around’ uses the form of the medieval dance of death...The prostitute says to the soldier: ‘who knows whether we will be alive tomorrow?’ and the young gentleman to the young lady: ‘Life is so worthless and then so short, so horribly short'” (Urbach, 1973 pp 78-84). Note that the last scene is the “only one where copulation does not occur. Although the count accepts the prostitute’s word...it is by no means certain that [the sex act occurred]” (Bennett, 1990 pp 121-122).

“The male characters are often in a hurry to get away from their partners once the sexual act is over: thus the soldier with both the prostitute and the parlourmaid, the young gentleman with the parlourmaid, and the husband with the sweet girl, whose observation that he is different after their intimacies sums up this phenomenon. By contrast, the reaction of the parlourmaid with the soldier and of the sweet girl with the husband following intercourse is to ask their partners whether they care for them. These conventional gender roles are not maintained, however; in the scenes between the young gentleman and the young wife and between the sweet girl and the poet it is the men who express concern about the women’s love for them afterward and the women who are in a hurry to get home, and in the play’s final scene even the count seems to wish he meant something more to the prostitute than the other men she has been with” (Finney, 1989 p 36). 

“A lioness who dominates all men- the poet, a former lover named Fritz, and the count- [the actress] is willful and selfish, a worldly woman who has overcome sexual vassalage to tyrannize over men. The count unwillingly submits to her and is bullied into a rendezvous. Yet her absolute control of her lovers is tempered by her awareness that her fame and beauty are ephemeral. The count, sexually cruel like the soldier, is sentimental and vulnerable like the young gentleman, the husband, and the poet. He is different in his philosophical and emotional sophistication, which is in conflict with the natural instincts aroused in a virile man who seeks pleasure in a woman-dominated society. His confusion in the prostitute’s room is both touching and deplorable. He yearns for some idyllic dream of pure womanhood while he is chained in the treadmill of pleasure and male egotism” (Grace, 1973 p 183).

Comic aspects of the play have been emphasized. &quot;One particular source of the comedy is provided by the very structure of the play, in that the audience gradually becomes aware that in each scene the two characters' words, behaviour, and above  all their sexual strategies are not to be viewed in isolation, but may either be compared with the preceding scene or judged in anticipation of the one that is to follow...The fourth scene is the first in which the sexual act seems mutually and lastingly enjoyable rather than followed by an abrupt change of mood on the part of one or both participants...[In scene five], from the very start, the young woman's surprise at her husband's renewed interest in her is revealed in her ironic comments...and the same irony underpins her laconic responses to his excuse that it is the sanctity of marriage which necessitates his frequent suppression of or, as she sees it, lack of erotic interest...One has the impression that they both finally make love to someone else or at least to a figment of their imagination...The comedy of the sixth scene is more muted than in the previous two, and derives principally from the recurrence of by now familiar motifs, not least the contrast between the woman's apparent attempt to keep her distance and an obvious enjoyment of intimacy...[In scene 7] the comedy of the scene results largely from the portrayal of the writer as a self-centred poseur who sees every situation, every sentence, as a potential literary gem to be used in a subsequent work...[In scene 8], the actress and writer reveal a consummate ability to act a part, thereby demonstrating in extreme form what the play suggests is a feature of all human sexual behaviour; in this particular instance, however, both characters appear to be in full agreement as far as the play's direction is concerned...[In scene 9] the count, unlike the writer, readily accepts as the truth the actress's protestations of illness and also her claim that she is a misanthropist, or that she was performing only for him...The mockery she had hurled at the writer is here used more sparingly and indirectly, no doubt out of respect for his military rank and concomitant social standing, but she quietly pokes fun at his philosophizing, his insistence on a schedule or on the importance of the right ambience for seduction, or which drives her to call him an old man...The concluding scene is also unusual in that there is no explicit comedy to speak of, certainly not by comparison with the preceding scenes, but merely a certain gentle irony at the count's expense which arises out of the contrast between his philosophizing and the prostitute's very down-to-earth approach...On the whole, however, the women are more witty and amusing, but also as a result more warm and sympathetic, whilst the men appear shallow and lacking in warmth and humanity. For all the male characters, empty philosophizing and a concern with order and ritual replace or even indicate a lack of genuine emotional involvement...The women, unlike their male counterparts, retain an awareness of past loves, with which they are happy to compare present experience. They appear to derive a more lasting pleasure from sexual experience, showing less furtiveness and fewer signs of post-coital guilt. Even the prostitute regrets that she could not sleep with the soldier in more comfortable surroundings, whilst the final scene finds her sleeping contentedly after her night with the drunken count. For the women, sexuality is a weapon that gives them a certain power over men, or at the very least an awareness of equality with them...It is scarcely surprising, therefore, that in the final scene [merriment] is indeed outweighed by [melancholy], as the cycle returns to the character who owes her raison d'être to the suppression of more natural and mutual sexuality that is codified in social convention&quot; (Roe, 1994 pp 676-687). Yet “attempts to make out that ‘The round-dance’ is darker and by implication deeper, a dance of death rather than a lively roundelay, suggest a wish...to find a moral framework for Schnitzler’s play without a moral. There is scant evidence in the text that the spectre of mortality is waiting in the wings” (Skrine, 1989 p 132).

&quot;All of Schnitzler's work reveals the influence of his home country and in particular the city of his birth and death, Vienna...One shows as much as the other Schnitzler's deep feeling about the right to live one's own life, the position of the artist in society, and the ever-present threat of death. It would be a shallow and philistine approach indeed to claim that Austrian man appears more clearly in Schnitzler's work just because specific reference is made to an Austrian setting. There is little doubt that in all of his writing man comes first and the local color interwoven in his characterization, second” (Kann, 1963 p 52). &quot;In Schnitzler's plays, it is always either spring or autumn. There are white lilacs or russet leaves- each with their nameless pathos. The people in his play- these Germans of the south- take life less sternly. They even discard it more gracefully, though they love it with so wise and warm a love. Most of them are extremely civilized, members of an ever-increasing class in the modern world. They have the power of seeing their passions objectively, of analyzing them; they have the gift of musical and subtle yet constantly natural speech. They seek the pangs that give meaning to life and a sense of infinity in the midst of impermanence. They will not avoid the austerer passions and duties; but they do not court them. Reflection has mellowed and tempered their innermost selves&quot; (Lewisohn, 1916 p 39).

“Schnitzler’s impressionistic dramas become progressively critical toward the spirit of the epoch, and not simply reflective of it. The one-acts are appropriate for reflecting the lack of development in the hero: life is seen as a series of interchangeable episodes…This is true of Reigen no less than of Anatol (1893): both cycles echo Nietzsche’s idea of cyclical return” (Wisely, 2004 p 83). “In Schnitzler’s day, it was the custom to drape the inner void and bankruptcy with sumptuous, borrowed costumes. This habit had almost become a kind of style. Schnitzler stripped off the trappings at the outset, tore off the masks and wiped the rouge off people’s cheeks. What was left was in truth not much, a little instinct and a good deal of fear, avowed or otherwise, a little bit of love or rather flirtation, that is [to say] playing with love, a wisecrack or two followed by devastating vapidity and emptiness” (Maurer, 1972). 

==Roundelay==

[[File:Collasius Ilse Ritter3.jpg|thumb|Always fond of theatrical displays, the actress kneels in prayer before copulating with a poet and a count. Played by Ilse Ritter (1944-?), Hamburg, Germany, 2001]]

Time: 1890s. Place: Austria.
 
Text at https://depts.washington.edu/vienna/documents/Schnitzler/Schnitzler_la_ronde.htm

A prostitute proposes to a soldier to come to her room. He has no money, but for him she is willing to offer her services for free. He objects her room is too far, so they copulate in the bushes. She then asks at least for carfare, but he refuses. In an amusement park, the same soldier tries to seduce a chambermaid. He sees another couple near. &quot;Others are like us,&quot; he points out, but she refuses to take the hint till he rubs himself on her. She complains she cannot see his face, but he considers that unimportant. They copulate in the dark. She then wants him to take her home, but he refuses, at which he cries out: &quot;Oh I know you, now it's the pie-faced blonde's turn!&quot; Nevertheless, she'll wait for him as he goes to dance. The next day, the chambermaid serves a glass of water to a young gentleman. He comments favorably on her blouse, opens it, and kisses her breasts. They copulate while the doorbell rings. He then gruffly goes out to a cafe. The young gentleman has a rendez-vous with a heavily veiled married lady who has qualms about their relation. &quot;You tormented me so. But I didn't want to do it. God is my witness- I didn't want to do it.&quot; she specifies. &quot;Yesterday I was absolutely determined...Do you know, I even wrote you a long letter last night.&quot; He knows she is unhappy. She is pleased to answer yes. She puts a candied pear on his lips. They go to bed, but he is unable to achieve a lasting erection. He recounts Stendhal's story about cavalry officers, who become impotent when in presence of the woman they love. She is about to go, but he manages to take her to his bed to copulate. She then worries about not having any excuse to invent to her husband because of the late hour. Back home, the married lady hears her husband say: &quot;If we hadn't sometimes forgotten...during the five years we've been married...that we were in love with each other, we certainly wouldn't be now.&quot; He adds: &quot;That's why it's such a wise thing from time to time to live together like good friends.&quot; Curious to know about his past, she asks whether there was a married woman among those he slept with. The question disturbs him. He asks her to promise this: &quot;That you'll never have anything to do with a woman who is the least bit under suspicion of not...not leading a quite spotless life.&quot; He adds: &quot;One can only love where one finds purity and truth.&quot; They go on to copulate. &quot;If only you'd always-&quot; she regretfully exclaims afterwards. &quot;One can't always be the lover, one has to enter the battle of life now and then, to fight and struggle,&quot; he declares. The next day, the husband treats a sweet young girl to a meal in the private room of a restaurant. She has not had a sweetheart for six months and accepted his invitation because he looks a little like him, and with the same name. The previous man was a rotter, leaving her in the lurch. Her head is swimming, he presses her. They copulate. &quot;Honest, I'm not like this...Honest to God- if you thought that of me...&quot; she confesses anxiously. She guesses that he is married and that his wife is doing the same thing. He protests to the contrary. &quot;Well, then- if you really want to be my sweetheart- mine alone- something can be arranged- even if I do live in Graz most of the time,&quot; he assures her. The next day, the sweet young girl is invited in a poet's room. Since she is hungry, he suggests a private room in a restaurant, to which she repeats the same story as she did to the husband. They copulate, an experience the poet considers &quot;transcendental bliss&quot;. He reveals that the name he gave her is not his own. &quot;I'm not Biebitz, but Biebitz is a friend of mine. I'll introduce him to you sometime. Well, on Sunday Biebitz's play is being given. I'll send you a ticket and then I'll pick you up at the theatre afterwards. You'll tell me how you liked the play, won't you?&quot; Later, the poet and an actress enter a room at a country inn. To his consternation, she kneels and prays, enjoining him to pray with her. Then she asks him: &quot;I suppose you'd like to have an affair with me, wouldn't you?&quot; They copulate. She then tells him she considers him a caprice. But yet she has fevers out of longing for him. &quot;A hundred and four degrees!&quot; she specifies. &quot;That's pretty high for a caprice,&quot; he notes, to which she replies: &quot;A caprice, you call it? I'm dying of love for you and you call it a caprice?!&quot; Later, in the actress's bedroom, a count meets with her. &quot;Last night you were literally showered with flowers and wreaths,&quot; he says. &quot;They're all in my dressing-room still,&quot; she replies. &quot;I took only your basket home with me.&quot; &quot;I'm never in the right mood till after supper,&quot; he specifies, but he finds the room hot. &quot;Do you think so?&quot; she asks, &quot;And it's dark, too, almost as dark as night. It is evening...it is night...close your eyes if it's too light for you. Come!...Come!&quot; The count resists no longer. In a poorly furnished room, the count wakes up next to the prostitute. &quot;Well, good luck to you. The wine's still got me. Really, that beats everything...I come to a female like this and don't do anything but kiss her eyes, because she reminds me of somebody. Tell me, Leocadia, does that happen to you often, a man going away like this?... I mean, men being with you- and not wanting anything from you?&quot; he asks. &quot;No,&quot; she admits, &quot;It's never happened to me before.&quot; She adds: &quot;The maid's up already. You might give her something when you go out. The street door is open, too, so that'll save you the janitor's tip.&quot; &quot;Well...it would have been beautiful if I'd only kissed her eyes,&quot; he murmurs. &quot;That would have been an adventure, almost...but I guess it wasn't to be...Ah, here, take this...Good night.&quot; &quot;Good morning,&quot; she corrects him. &quot;Oh yes, of course...Good morning...good morning,&quot; he echoes.

=Frank Wedekind=

[[File:Frank Wedekind.jpg|thumb|Wedekind revealed the woes of adolescence and the force of love or lust in two dramas]]

Frank Wedekind (1864-1918) is another important playwright, especially for &quot;Frühlings Erwachen&quot; (Spring awakening, 1891) and &quot;Erdgeist&quot; (Earth-spirit, 1895).

Some early critics of Spring Awakening were offended by the outspokenness of the dialogue and the mores of the adolescents: &quot;these adults were depicted also as being singularly stupid, and the younger generation as being singularly degenerate, far more so, let up hope, than is usual with physically healthy children, as the children in this play seem to be. Of course, all understand that the playwright, in order to drive home the lesson he seems to think necessary, has focussed not only all the ills of early youth, but all the possible ills, and such a method will make an awful picture of any season of life or state of being&quot; (Elliott, 1912 p 237). In contrast, the author is also seen as quivering &quot;with the hatred of the honorable man against the hypocritical sublimation of natural deeds into spiritual ideals, against burdening flights of imagination with occupational duties, against the transformation of sense, song, and image into educational subject matter” (Gundolf, 1972). Wedekind &quot;unfolds a tragedy of adolescence, the psychology of which is so manifestly true that one can bear the repellant details. Sex love to him is wholly sensual, a mad lust of the flesh; but in this children's tragedy he is attacking the pernicious system of repressing the facts of sex in training youth. Like Cosmo Hamilton's milder play, The Blindness of Virtue, it argues for educated virtue rather than dangerous innocence. Wedekind's view of love is different from that of Strindberg's clean hatred of its arbitrary power, or Shaw's good-humored explanation of it as an impersonal cosmic force for race perpetuation, or the cloying beauty of D'Annunzio's presentation of it as a languorous disease, or the worldly sentimentality of Schnitzler's characterization of its charm and impermanence&quot; (Burrill, 1920 p 31). Spring Awakening is &quot;sex awakening&quot; (Dukes, 1911 p 101). “It is the conflict of the generations that links this otherwise unique play with the history of German literature: with the movement of Storm and Stress. As to technique, it is Buchner's Wozzeck with its many short and loosely connected scenes that comes to mind. The peculiar atmosphere of adolescence, the psychological insight into the daydreams, emotions and conversations of young boys and girls is Wedekind's” (Hill, 1960 p 84). “The separation between the generations, between the sexes, between public morals and personal inclinations, had progressed to the extent that the direct confrontations and inexorable chain of events upon which classical tragedy had been based were no longer conceivable. There is no scene in the play where the younger and older generations clash as equals. The only scene where a direct confrontation begins to occur is the teachers’ conference, but Melchior’s protests against their inquisition are immediately stifled (act 3, scene 1)”  (Jelavich, 1985 p 90). The subject of puberty in Spring Awakening is presented with &quot;unprecedented candor&quot; (Garten, 1964 p 88). The author underlines &quot;the moral cowardice of the parents&quot; and the &quot;narrow-mindedness of the teachers&quot;. The language of the young is &quot;lyrical&quot;, the language of the parents &quot;matter-of-fact&quot;. &quot;Never was a more powerful indictment hurled against society, which out of sheer hypocrisy and cowardice persists that boys and girls must grow up in ignorance of their sex functions, that they must be sacrificed on the altar of stupidity and convention which taboo the enlightenment of the child in questions of such elemental importance to health and well-being...Melchior's mother, a modern type, has greater faith in her child than in school education. But even she cannot hold out against the pressure of public opinion; still less against the father of Melchior, a firm believer in authority and discipline...The child is the unit of the race, and only through its unhampered unfoldment can humanity come into its heritage. Spring Awakening is one of the great forces of modern times that is paving the way for the birth of a free race&quot; (Goldman, 1914 pp 119-128). “When the adult world intrudes into that of the adolescent, it is shown to be incapable of sympathetic understanding and totally self-centered- even where it appears to be trying to help” (Best, 1975 p 66). “Whereas the children experiment with roles and attitudes, the adults are rigidly hypocritical or self-deceived. The mask of moral authority conceals hidden desires for power, status and sexual gratification. In the name of morality, but in reality to satisfy personal desires, they abuse the children or attempt to impose their own ideal self-image...When Moritz fails to reproduce his father’s self-image of competent success, Rentier Stiefel denies paternity...The boys project their guilt on the object which arouses sexual desire- Melchior beating Satan out of Wendla- while girls helplessly accept their own guilt as grounds for punishment...Wendla is fascinated by the beatings Martha’s father inflicts on her, and twice asks what he hits her with” (Boa, 1987 pp 35-41). &quot;Wedekind set himself the task of describing and interpreting the sexual difficulties of adolescence...Each scene, moreover, though of a haunting reality of impression, is lifted above the physical crassness of its incidents by a strange remoteness of speech and gesture that clings to all the characters. Thus even the incredibly daring incident in the reform school fills one with compassion rather than with disgust. It is not hard to disengage in fairly exact terms the thoughts to which the shifting scenes of the play correspond: the youth of the race is seized at a certain period by inevitable instincts and passions. Society is so organized, however, and conventions are so fixed, that youth attains no clarity concerning these instincts, but struggles with them in the lurid twilight of ignorance and of fantastic guilt. Thus bodies are corrupted and souls perverted by the mysterious degradation of the race's very condition of continuance. A morbid importance then surrounds the instinct of sex; it penetrates all the recesses of the nature; it becomes unclean; it gives rise to practices that deepen the evil and unnatural sense of guilt. These facts no sane observer of society will deny. In Wedekind's play they are rendered objective in a manner that will deeply stir the mature mind to compassion and reflection&quot; (Lewisohn, 1915 pp 151-153).

“The title of the play, [Earth Spirit], refers to the Earth Spirit in Goethe’s Faust, the life-force that Faust conjures up but cannot capture because his intellect cannot come to grips with vital and sensuous nature. Lulu is Wedekind’s Earth Spirit, and like that of Goethe, she remains incomprehensible to the men that surround her. She is a street orphan whose background is shrouded in mystery; she does not even know her real name” (Jelavich, 1985 p 106). “The dialogue is terse, stylized, and staccato [and has been] compared with the Expressionist” (Brown, 2008b p 167). &quot;Instances in which physical action is either the exclusive and co-equal means of communication are readily found. For example, the entire last scene of Erdgeist is conceived in terms of two distinct levels: Lulu is confronted front stage verbally by Aiwa and his father, Dr Schön, the latter accusing her of keeping company with the former, while backstage her other hangers-on, Rodrigo, Hugenberg, and Gräfin Geschwitz, surreptitiously move among various hiding places. The rather chaotic mimic action in the background (facilitated by a set with a balcony over the stage) is in contrast to the front-stage dialogue and subtly underlines its import. This contrapuntal nature of the final scene is none other than a comment- in spatial language- on the contradiction between Lulu and the world imposed on her&quot; (Jones, 1970-1971 p 286). Lulu “must perform her role as a sexual object and try to sustain the attention of multiple men as the only means available to her for advancement. The portrait of her that travels throughout the play is meant to juxtapose the contrasts between the fixity of her identity in the painting and the ever changing nature of her role playing” (Krasner, 2012 p 223). Garten (1964) described Lulu as many critics have: “soulless, callous, driven only by her animal instincts, leading man after man to his ruin” (p 90-91). &quot;As Schwartz probes Lulu to discover her identity, he discovers that “she has no sense of sin or guilt...To each man she is something else and indeed each one has a different name for her...[In Freudian terms, she is]...the representation of the pleasure principle [of immediate gratification], receptiveness” (Gittleman, 1969 pp 68-73). Wedekind &quot;was not content with degrading man to the level of a mere animal governed by instinct and conditions of habitat, but proceeded to make of him a ravenous and filthy beast...Lulu...is passion and vice incarnate, a genuine beast of prey who is responsible for the death of her three successive husbands. To be sure these were little better than she. She has no conscience and is never disturbed in the least by a consciousness or a feeling of guilt&quot; (Cast, 1917 p 530). “Her men grow soft and find they lack the strength to cope with her. In the face of her impassivity, they sense their own folly and impotence, fall prey to delusions of persecution, and bring on their own demise...She is at one and the same time a ‘femme fatale’ and a 'femme enfant’ [child-woman]...The interpreters of Lulu fall roughly into two categories. The first group sees her as a mythic creature...victimized and betrayed by the men in her life...The second school...finds her demonic and ruthless in exploiting her power over men” (Chick, 1984 pp 13-29). &quot;Each of Lulu’s men believes holding the key to her true nature...Schön understands that she will destroy Escerny, but yet he is himself too weak to withstand her charms. She 'represents the illusion of joy' to the men around her 'and she seems incapable of experiencing joy herself'&quot; (Whalley, 2002 pp 60-61). Hibberd (1984) was more indulgent. Lulu &quot;may be given various names, but essentially she does not change with the name she is given. Each name may, however, reveal something about her as well as about the person who applies it to her. Her first unfortunate husband, Goll, calls her Nelli. If this is an abbreviation for Helen it suggests her beauty and her threat to the peace of her husband and of men in general...Her second husband, Schwarz, calls her Eve and thus unwittingly points to her perilous potential. Schön dubs her Mignon, recalling the charm and mystery of the young temptress of Goethe's Wilhelm Meister, perhaps too her nostalgia for a long-lost happier past...Lulu is in many respects a child...Alwa expresses his approval of these childlike characteristics which are, he thinks, emphasized when she is dressed in white. He thinks of her strange innocence. But his awe for this facet of Lulu must also be seen in the context of the belief that children were more ready to accept and enjoy life and that natural vitality was sapped by the process of maturing and social assimilation. She is body, matter, instinct; she is irrational beauty, the triumph of nature, the spirit of the flesh. She is essential to the survival of vitality and to creativity, but is also, at least under certain circumstances, destructive...Each of the male characters represents a variation of [spirit] in its opposition to instinct...Her lack of feeling is an invention of her critics. What she lacks is sentimentality...Her self-centredness represents an ethic based on fundamental honesty...Her lack of conscious reflection and her fierce rage for life mean that she is sometimes insensitive to the feelings of others...If she has so often been seen as the evil destroyer of men, it is because audiences and critics have shared the attitudes of the male characters in Wedekind's drama&quot; (pp 342-354). “Wedekind emphasizes the elusive quality of Lulu’s identity by placing her in artistic settings, evoking the archetypical dichotomy between reality and illusion. As an artist’s model and music hall performer, she inspires visions that have little to do with her quintessential reality, but the subjective vision of each artist or member of the audience (men-lovers) makes Lulu fascinating. Proud of her ability to change clothes rapidly, she boasts that she can effect a transmogrification without assistance of a female dresser but asks the nearest man for help to fasten a hook or adjust her bodice” (Grace, 1973 p 198). “Naïve, comic, yet also pathetic, the pierrot figure was associated with wordless mime which conveyed its childish joys and sudden despairs; Lulu’s portrait as a pierrot enabled Wedekind to remind audiences...of her essential vulnerability. She is of course the central figure...but she never says very much and what she says is hardly memorable. Yet she holds our attention...just as she holds that of the men in her life” (Skrine, 1989 p 89).

Wedekind's main influence is Georg Büchner (1813-1837) in terms of subject matter and literary style often characterized by short scenes indirectly related to each other (Rapp, 1947, p 99). Some early critics were offended at Wedekind’s exposure of corruption. In the view of Witkowski (1909), Wedekind has &quot;a completely vicious nature, at the same time [is] artistic through and through, driven from desire to enjoyment and in enjoyment languishing with desire, despising himself just as much as he does those who think they find in his work any lofty aim whatever. The omission of all reference to the supernatural and the conception and use of existence as of a mere given fact, is shown in its last artistic consequences in a horrifying manner in Wedekind's writings&quot; (p 181). Chandler (1914) opined that “in Wedekind, we have a nature corrupt and unclean, rejoicing to explore the foulest sores of society for no other reason, it would seem, than the pleasure of laying them open” (p 292). Wedekind’s dramatic “personages sprang from the half-world of the decadent and the underworld of the declassed; the bohemia of adventurers, artists, whores, and pimps had taken over the revolutionary mandate from the cast of the bourgeois drama. An idealist and moralist experiences tragedy in his collision with the reality of the turn of the century, challenging it with the grimace of his humor” (Drews, 1972). “His business is to make jokes and through a long list of somewhat formless plays he has jeeringly added to his gallery of characters from modern German life with a biting wit and a command of the resources of the German language that place him to the head of the German dramatists of today” (Moderwell, 1972 p 237). &quot;The dialogue generally is jerky, as though marionettes were speaking; and Wedekind and his wife acted in his own plays with the stiff movements of wooden dolls. Wedekind is the creator of a new genre, the gro- tesque drama of manners, and in this respect, as in his rejection of the accepted canons of decency, he is the acknowledged prophet and forerunner of expressionism. To some extent his characters are, as in expressionist drama, types rather than individualized characters. The butt of his vitriolic attack is conventional morality, but he himself, in repeated self-interpretation through the mouth of his characters, claims to be a moralist, and, incredible as it seems to us, the claim has been upheld by the most serious academic critics of Germany&quot; (Bithell, 1959 p 54). But in the view of Garten (1964), Wedekind represents &quot;a fresh breeze&quot; in the &quot;stuffy atmosphere of late nineteenth century&quot; (p 94). As Dukes (1911) averred, &quot;where other dramatists touched delicately, for fear of over-boldness, upon the woman with a past or the life of the demimonde, he dragged pathology, sex perversion and insanity relentlessly upon the stage&quot; (p 96).

&quot;The exact character of Wedekind's power over the younger generation can be best observed in the plays of Carl Sternheim and Georg Kaiser. Both have richer natures. But what Wedekind taught them was how to attain dramatic range through speed. He broke up the dramatic continuity which he considered as but productive of a futile illusion and sought sweep, variety, and also concentration by lifting his characters at crucial and frankly isolated moments out of the darkness into a strong and sudden light. Within these apparently random scenes hurled on the stage, he likewise makes no effort to produce an illusion of reality. All gestures become symbols; all speech races toward its ultimate significance. A terrible yet hopeless avidness after the meaning of life dominates this drama, and under its cold cynicism you feel a stifled moan of pain&quot; (Lewisohn, 1922 pp 153-154). Wedekind &quot;produced in the two parts of Lulu- Erdgeist and Pandora^s Box- dramas horrifically actual in their pictures of sexual aberration and at the same time so intense psychologically and so sharply defined and apt in action that their realism treads close on the boundaries which expressionism has over-passed&quot; (Macgowan and Jones, 1920 pp 28-29).

==&quot;Earth-spirit&quot;==

[[File:Lili_Marberg_als_'Lulu'_in_'Erdgeist'_-_Franz_Grainer.png|thumb|Played by Lili Marberg (1876-1962) and photographed by Franz Grainer (1871–1948), Lulu makes her living by manipulating men]]

Time: 1890s. Place: Germany.

Text at http://www.gutenberg.org/ebooks/29682 https://archive.org/details/FrankWedekindPlays  https://archive.org/details/in.ernet.dli.2015.41909 

Schön has been Lulu's benefactor since her childhood and has arranged her present marriage with Dr Goll, who asks Schwarz, an artist, to paint her portrait in the form of a pierrot. As Goll leaves them, Schwarz can control his lust no longer, chasing her about the studio until hr hears a knock at the door. It is Goll returning. Deeply suspicious, the husband knocks the door down and, in his torment, suddenly dies of a heart attack. Schwarz then marries Lulu, but she quickly becomes bored with him, since he prevents her from continuing a career as a dancer. He is blind to her escapades. Schön advises Schwarz to be firmer and to use authority over his flighty wife, especially when one considers her background. Schwarz is devastated at hearing about her background. In despair of ever changing her, he heads toward the adjoining room and cuts his throat with a razor. This enables Lulu to return to a dancing career. Backstage during one of her performances, Prince Escarny asks her whether she would be interested in leading a quiet life at his mansion in Africa. As she returns onstage, Lulu has a fainting fit. As Schön rushes backstage to find out what happened, she says her weakness was caused by seeing him with another woman. She then mentions Escarny's offer. From this and other reasons, Schön realizes he cannot do without Lulu and so marries her. It does not take long before Schön become suspicious about his wife's activities. He takes a gun on his way to spy on her. Countess Geschwitz, a lesbian friend of Lulu's, also decides to spy on her. One fateful day, Lulu welcomes Schigolch, once known as her father, together with a friend, Rodrigo, and Hugenberg, a student. Schön's son, Alwa, comes in to join them. On his knees, a despairing Alwa reveals his love to Lulu. From his hiding place, Rodrigo notices Schön with a gun aimed at his head. He points his finger towards Alwa, signifying that the husband should shoot the lover, not he. As Schön walks in to speak with his son and they leave together in the adjoining room, a nervous Rodrigo looks about to change his hiding place, but on lifting the table-cloth, he sees Hugenberg under the table and finds another place to hide. Schön returns alone to find Geschwitz. Despairing over his wife's infidelities, he calls Geschwitz &quot;avenging angel&quot;, &quot;inexorable fate&quot;, &quot;hangman's noose&quot;, requesting her to commit suicide. Instead of that, she shoots him to death. As policemen knock at the door, Hugenberg fears to be expelled from school.

==&quot;Spring awakening&quot;==

[[File:Alexander Moissi.jpg|thumb|In a repressed environment, Moritz, played in 1906 by Alexander Moissi (1879-1935), has every reason to feel dejected]]

Time: 1890s. Place: Germany.

Text at http://www.gutenberg.org/ebooks/35242 https://archive.org/details/FrankWedekindPlays https://archive.org/details/awakeningofsprin00wedeiala https://pdfcoffee.com/spring-awakening-pdf-free.html

At fourteen years of age, Wendla insists on not wearing her mother's choice of a long dress. While preparing for school-work, Melchior and Moritz speak of adolescence. Moritz asks him to complete this form of education by writing about it. With Wendla and Thea present, Martha says that she is not allowed a blue ribbon through the top of her chemise. &quot;Mamma pulled me out of bed by the hair,&quot; she reveals, &quot;then papa came in: rip- he tore off my chemise. Out of the door I went...I had to sleep all night in a sack...If I ever have children, I will let them grow up like the weeds in our flower garden.&quot; Moritz secretly finds out he has been promoted. &quot;Lord, but I'll grind from today on!- I can say so now- whether you believe it or not- it's all the same now- I- I know how true it is; if I hadn't been promoted I would have shot myself,&quot; he says. In the woods, Wendla reveals to Melchior what Martha said to her concerning her parents' strictness. On seeing him casually holds a switch, she goads him. &quot;Would you like to beat me with it once?&quot; she asks. Instead, he beats her with his fists while tears stream down his cheeks, then he springs away. Back in his study, Melchior continues to speak of intimate subjects to Moritz, who says that he imagines a woman's pleasure in love as being greater than a man's. After being made an aunt three times, Wendla asks her mother about birth. &quot;How does it happen?- How does it all come about?- You cannot really deceive yourself that I, who am fourteen years old, still believe in the stork.&quot; &quot;To have a child, one must love the man to whom one is married, love him, I tell you, as one can only love a man,&quot; her mother answers. &quot;One must love him so much with one's whole heart, so- so that one can't describe it! One must love him, Wendla, as you at your age are still unable to love- now you know it!&quot; Despite his brutish behavior in the past, Wendla meets Melchior in a haymow. He asks her to leave him, but she chooses to stay. But then he notices her enticing body and kisses her. She recoils, sensing his lack of love. “People love when they kiss,” she states. Don’t, don’t.” “Oh, believe me, there's no such thing as love,” he declares “everything is selfishness, everything is egotism. I love you as little as you love me.” Despite her cries to stop, he rapes her. In the academic field, Moritz eventually fails. Despite an encouraging letter from Mrs Gabor, Melchior's mother, he contemplates suicide. He meets Ilse, a poor girl leading a bohemian life. She knows a friend, Heinrich, who put a gun to his mouth. &quot;Is Heinrich living yet?&quot; he asks. &quot;How do I know!&quot; she answers. &quot;Over the bed was a large mirror set into the ceiling. The room seemed as high as a tower and as bright as an opera house. One saw one's self hanging down bodily from heaven. I had frightful dreams at night- O God, O God, if it were only day!&quot; He tells her he must go, burns Mrs Gabor's letter, and commits suicide. After finding a text in Melchior's room, the rector avers to his colleagues that he must be held partly responsible for his friend's death. &quot;It grieves us deeply, gentlemen,&quot; he confesses, &quot;that we are not in a position to consider the other qualifications of our guilt-laden pupil as mitigating circumstances. An indulgent treatment, which would allow our guilty pupil to be vindicated, would not in any conceivable way imaginable vindicate the present imperiled existence of our institute. This manuscript, in the form of a dialogue entitled “The nuptial sleep”, illustrated with life-size pictures full of shameless obscenity, has twenty pages of long explanations that seek to satisfy every claim a profligate imagination can make on a lewd book.&quot; As a result, Melchior is expelled. While spreading anemones over Moritz’ grave, Ilse says that the reason he gave as to why he shot himself was a parallelepipedon. She will keep his pistol as a souvenir. Mrs Gabor is against her husband's determination of sending Melchior to a house of correction, threatening to divorce him, but when she discovers her son's letter to Wendla concerning their sexual relation, she changes her mind. Wendla is sick in bed during her pregnancy and blamed her mother for neglecting to inform her about the nature of sexual relations. Melchior escapes from the reform school and discovers Wendla's grave, killed by abortives. Moritz' ghost then enters, his head under his arm. The dead &quot;laugh at tragedies&quot;, see lovers as &quot;deceived deceivers&quot;. Wishing to guide Melchior onward, a masked man commands Moritz away, who submits. &quot;I will go back to my place, right my cross, which that madcap trampled down so inconsiderately, and when everything is in order I will lie down on my back again, warm myself in the corruption, and smile,&quot; Moritz promises.

=Max Halbe=

[[File:Max_Halbe_1900.jpg|thumb|Max Halbe showed that the elderly cannot curb youth's temptations, 1900]]

Also of note is Max Halbe (1865-1944) for &quot;Jugend&quot; (Youth, 1893).

Youth is &quot;the psychology of adolescence: these young people awakening to the facts of life expressed their feelings in language not unnatural but charged with poetry; and there was an air of reality and inevitability in the events, which in the girl’s case might be explained by the laws of heredity&quot; (Bithell, 1959 p 51). 

Halbe &quot;took the subject of the first sudden development of the sexual impulses. He had thus chosen a subject than which none could be more favorable for impressionist reproduction. Into a single moment is crowded the development of the suddenly growing passionate feelings and what seems new in every single case is in truth a typical incident in the truest sense arising from the most primitive impulses. Halbe made also a happy hit in that he placed the lovers in the simplest environment and did not obscure the developments of the physical life by any conditions of higher culture. Her surrender to overpowering impulses brought the girl, who is sketched with charming freshness and without any false naiveté, to the inevitable conflict with her innate moral ideas which had been strengthened by training and her lot in life and the idyll becomes an inexorable tragic fate. Even those who took a negative position in regard to naturalism were deeply moved by his drama&quot; (Witkowski, 1909 p 176).

&quot;What glorifies the play, for I can use no lesser word, is the exquisite picture of young love, consciously touched with tragedy, but irresistible, the loveliness of a sane instinct unblunted, unvitiated by the wrongs, the sins, the violences of life. Thus love may have come and almost thus been tasted in some morning of the world. Yet the reality of the scene and of the passion is complete. For a few days these two young creatures forget society, or strive to forget it: Hans, his necessary career, Annchen, her social asset of chastity. That is all. Any other way of ending the play would have served equally well. The lyric cry that may be at the heart of the homeliest reality, the hymn of love that may be heard by the simplest souls, has been uttered&quot; (Lewisohn, 1915 p 137).

Max Halbe's &quot;enriched naturalism...with the highly lauded 'Youth'...describes racial antagonisms between Poles and Germans in Prussia and dramatizes the tragic awakening of two youngsters who fall in love only to have their happiness destroyed. As in Hauptmann’s work, heredity is the invisible protagonist of the play. The girl, Annchen, born out of wedlock, has inherited her mother’s passionate disposition; the half-wit brother, who kills her accidentally, was crippled by his mother's frantic worry concerning her daughter's illegitimacy. Humanizing the rigors of naturalism with much tenderness, Halbe won an honorable place in the theatre. His specific contribution, the study of adolescence, introduced a rewarding subject to realists&quot; (Gassner, 1954a pp 471-472).

In general, Halbe “has first-rate technique and seems to know the stage well. The underlying idea is generally good, and his power of expression is not to be despised. But when the end of the play comes, we see no overwhelming reason either in the character of the persons or in the events portrayed to draw the same conclusion” (Harris, 1913 p 170). “Max Halbe has completely eliminated the conception of guilt. His characters are never guilty. They are the slaves of a modern fate, their own passions and the powerful forces of their environment. Engaged in an hopeless struggle, they are quite unconcerned about ethical or moral standards” (Cast, 1917 pp 529-530).

==&quot;Youth&quot;==

[[File:Logo_University_of_Heidelberg.svg|thumb|Hans intends to start courses as a student at the University of Heidelberg, but is prevented by a mentally defective youth under the throes of jealousy. Seal of the University of Heidelberg]]

Time: 1890s. Place: Rosenau, West Prussia.

Text at https://archive.org/details/youth00halbgoog https://archive.org/details/youth01halbgoog
https://archive.org/details/youthmal00halbuoft

Since both of her parents died, Anna has been keeping house at the parsonage of Reverend Hoppe, her uncle, and taking care of her mentally handicapped half-brother, Amandus, much dependent on her. Amandus picks up the first radish of the spring from a dungheap and places it on the living-room table. While Reverend Hoppe and Anna talk, he stares at it for some time and then devours it with great relish. Anna gently scolds him. “Youth! They are in such a rush,” Reverend Hoppe comments. “They would like best of all to build Rome in a day. Later, when one gets along in years-” muses the uncle. He receives a letter announcing a visit from Hans, his nephew, whom Anna knew as a child, on his way to the University of Heidelberg  as a student. Seeing Anna glad of his arrival, Father Schigorski reminds her of his wish for her to enter a convent, all the more to expiate the sin of her mother, who bore her out of wedlock. She is reluctant to do so. When Hans suddenly arrives, she welcomes him in blushing confusion. Together alone, they very quickly sympathize. In a spontaneous rush of feeling, he flings himself over her and kisses her madly while she throws her arms around him and returns his kisses. As they hold each other, Amadeus observes them, peering through a crack of the door, and is ushered out by Anna. As Hans embraces her again, they are interrupted by Father Schigorski, who takes in the awkward situation. Amandus returns but hides behind the linen press, then rushes out the door. Expecting a visit of at least one month, she is disappointed when Hans declares he is going in two days. Next morning, Anna scolds Amandus for his rudeness towards their cousin. When she boasts of her cousin’s intelligence, Amandus points out his physical strength. A nettled Anna retorts that it is so when he trips him from behind as he did that morning. Amadeus rages in a fit of jealousy. Looking gloomier than ever, Father Schigorski warns her about her cousin. “Listen before it is too late. There is recklessness in your family. Think of your mother, Pannie,” he says. As Amandus looks out of the window at Hans carrying his uncle’s gun, he rises as if aiming with it, his eyes sparkling. “Bing! Bang! Dead!” he cries. Hans enters with the gun and puts it down. Amandus looks it over. When reminded that Hans is leaving the next day, Anna avers absent-mindedly that he will not and fetches the cakes she baked for him. Alone together again, she pleads for him to stay at least five more days, or why not forever? “You stay here and learn Polish and help uncle look after things,” she suggests. “We have enough to do here, too, if we want to. And afterward you get your parents to give you some money, and buy a large estate here. And then you will not go away at all, then we shall always be together.” As she heads towards the drawing-room with Reverend Hoppe and Father Schigorski to play music, a grinning Amandus approaches Hans with the gun. When Hans asks for it, he quickly goes out. That night, Anna enters Hans’ room, an encounter spied on by Amandus. The next morning, she sits at the living room in limp misery. Hans promises to stay by her, but he also wants to go to the university as planned. Father Schigorski announces that he has read the mass for her mother's soul, at which she sobs, having forgotten it. Amandus gobbles several cakes prepared for Hans. When Anna scolds him, he throws the rest at her feet. “Will be revenged,” he growls maliciously. “Tell everything, give everything away.”  Sure enough, he tells about Hans' nighttime visit to his half-sister's room late at night to Father Schigorski, who in turn reveals it to Reverend Hoppe. Father Schigorski rips up the letter from the mother superior announcing that she may enter the convent and refuses henceforth to act as her confessor. Reverend Hoppe is stunned at the mention of the letter, for which he was not consulted, and dismisses Schigorski from his service. Recognizing the importance of Hans’ university studies in his career, the reverend proposes that he should leave immediately, at which the student reluctantly agrees. But before he can go, Amandus, gnashing his teeth, advances with the gun again and levels it at him. An anguished Anna steps between the two and is shot to death.

=Hermann Sudermann=

[[File:Sudermann, Herman by Nicola Perscheid.jpg|thumb|Hermann Sudermann showed how returning home sometimes leads to unhappiness. Photo by Nicola Perscheid]]

Hermann Sudermann (1857-1928) best achieved his dramatic art in &quot;Heimat&quot; (Home, 1893). 

In Home, &quot;the theme is very cleverly presented so that a mild light falls on the old-fashioned society with its limited view-points, its rigid but at the same time firm and bracing ethics, its self-sacrificing spirit and its modesty, while the newly gained freedom of the individual who strives upward by his own effort is woven about with a gleaming splendor. In Magda, the representative of this new nature, he has created a captivating role and has besides scattered throughout the whole play such a great variety of striking external effects that he has given to the stage a work whose international success has only been attained, among all German dramas, by Kotzebue's 'Misantropy and repentance' (1789)&quot; (Witkowski, 1909 pp 156-157).

Home &quot;is one of the finest technical accomplishments in all modern drama, practically every element of the well-made play- unity, clearness, and a well-defined struggle- is here skilfully adapted to a modern theme. The entire first act is exposition, exposition of the best kind. The important characters are introduced, or- as in the case of Magda herself so constantly spoken of that they are well known before they appear; the history of the past is unfolded, the spirit of the 'home' makes itself felt almost immediately, and the struggle between the old and the new, between Schwartze and Magda, set in movement...The contrast between the old and new orders, between the old German idea of home and the new idea of individual development, begun in the first act, is continued throughout the play; in the first act, the spirit of the old was brought before us by means of conversation, in the second, it is set forth in the struggle between two persons- Schwartze and Magda- and in the third it is both discussed and acted. Magda's playful banter, the little humorous touches in her scene with the servants, the provincial wonderment of Franziska and Mrs Schwartze, all contribute to the central idea. In addition, the first few pages of the third act form an interlude between the rising action of the second and the tension that is to increase later in the third act. The scene between Magda and Marie is a 'bridging section' or connecting link between the 'interlude' and the Heffterdingt- Magda and the Schwartze-Magda colloquies, which are followed by further scenes of varying tension, through that between Magda and Von Keller, to the culminating point in the act, in which Schwartze and his 'erring' daughter go into the former's room, each having 'something to say' to the other. So far, the end of each act has been emotionally higher than the beginning, as well as tenser than the end of the preceding. The first, second, and third acts have each culminated in a crisis; while the end of the third act was the greatest crisis- that fraught with the utmost importance to the chief characters- in the play that was: the beginning of the climax. But the actual climax occurs off-stage in the interval between the third and fourth acts. This is a more effective method than as if the clash had occurred upon the stage, because we see the beginning, imagine the struggle, are ignorant for a few moments of its outcome, and when the curtain rises on the last act, are still in suspense. In this way, there is no relaxation of pressure. The climax started in one act is carried over into the next and does not end until Schwartze enters, as we see, defeated&quot; (Clark, 1915b pp 110-112).

“What grows especially on one, the more familiar he becomes with Sudermann's Magda is the hopelessness of lieutenant-colonel Schwartze. At first, when the drama was new, there seemed to be, to one who fancied that he had some notion of the provincial German's strange and perverted idea of honour, sufficient excuse for the pig-headedness of Magda's father to permit one to bestow on him the atom of sympathy that was necessary in order to bring the character within the range of possibility. Upon further acquaintance with the facts of the case, however, every vestige of sympathy vanished, and old Schwartze stood forth a selfish, obstinate, unreasonable, and inhuman brute, who deserved to die, if ever any one deserved to die. Undoubtedly, Mrs Campbell's human Magda, as contrasted with Mr GS Titheradge's exceedingly blunt and unsoftened Schwartze, helped in their presentation of the play to emphasise this condition of things. Still, I am convinced that the condition is really inherent, though it may sometimes be tucked partially out of sight by less pronounced acting. In fact, wholly to eliminate it would be to ruin the motive and purpose of the drama. The evidence in the case bears out this theory. Schwartze, it will be remembered, was guilty of the first error. His daughter refused to marry the minister, and he drove her from his house, a punishment altogether out of proportion to the fault, if fault it actually was. Eleven years passed without his especially troubling himself about her. He did not know, indeed, whether she was alive or dead. At the end of that time, however, she unfortunately yielded to a sentimental weakness- it was scarcely more than that, though coupled with it was a lingering affection for her younger sister. She accepted an invitation to sing in her native town, reentered her father's house, succumbed again to sentiment as against her better judgment, and consented to stay there for the time being. The moment that this outcast daughter once more came under his roof, the father usurped the authority that eleven years before he had violently and cruelly relinquished; and he presumed to question this woman, whom he had forced unprotected into the street, regarding her conduct during the period of her freedom. He attempted to order her present and future life according to his own narrow and conventional code of righteousness and morality. Naturally his will was steadfastly opposed; it was right that it should be opposed. Magda had sinned, but she had expiated her sin with tears and toil and achievement; she had striven and risen far above her old self; she was in every sense a strong, upright, and noble woman. Schwartze, too, had sinned, equally with his daughter- even more so, for he was directly responsible for her sin; but he had not expiated his sin. He had indeed suffered, but his suffering had not brought him to a realisation of his own fault. His suffering he blamed upon another; his sin he cherished, and he continued to cherish it, until in the end it killed him” (Strang, 1903 vol 2 pp 260-263).  

Several critics were displeased with the presentation of the central character in which &quot;naturalism was wedded to a mellow sentimentality, caressing to audiences bred upon the drama of perfumed adultery&quot; (Mencken, 1921 series 1 p 106). An exasperated Winter (1913) declared that &quot;no woman has appeared in recent fiction who affords a more salient example than is presented by Magda of almost every repulsive attribute possible to a female character. She is vain, silly, perverse, obstinate, self-willed, unchaste, ugly in temper, and absolutely selfish. Such a character might be serviceable as an incident in a drama, but as the total subject of a drama it is out of all proportion, and it becomes both offensive and tedious (vol 1 p 314). &quot;Magda does not regret her past irregularity, since she feels that it has formed her character. When her father learns of her past, she defends her title to freedom as the only privilege left to an outcast. Yet in her lame diatribes against the family as an institution, and in her intimation that she has had more lovers than one, Magda forfeits the sympathy that the recital of her sufferings had aroused. To the pastor she defends herself by saying: 'We must sin if we wish to grow. To become greater than our sins is worth more than all the purity you preach'&quot; (Chandler, 1914 p 128).

Many critics have disagreed that Magda forfeits our sympathy. Magda &quot;is in revolt against that sacrifice of womanhood which a false ideal of the home life entails. Her spirit is too free, too eager to touch life at many points, too restlessly conscious of power in itself, to brook the small and narrow surroundings in which convention would have kept her imprisoned&quot; (Caffin, 1908 pp 149-150). &quot;Magda, if you examine her keenly, has certainly adopted some of the mannerisms of travelling celebrities. At moments she exhibits those peculiarities of which we read so much in interviews and paragraphs, but, 'au fond', inwardly, this girlish woman, bred and born in German provincialism, is nothing but the Hausfrau with the polish of worldliness and obedience to convention, and, therefore, to filial subordination. Greater in her is the desire to settle down in life, a restful and respected woman; greatest of all is her spirit of maternity. Therefore, the right note, the human note, in which to play Madga is simplicity, repose, tenderness&quot; (Grein, 1905 p 264). &quot;The struggle that ensues between the woman's individualism and the old set of conditions is moving in the highest degree. It is set forth with much skill of character portraiture and contrast, in striking situations leading up to a logical and impressive climax. Throughout, the theories of individualism supported by Magda are presented not in mere talk but in illustrative action. One of the strongest passages in modern drama is that in which, instead of reproaching the pompous, mean-spirited coward, once her betrayer, now a respected and pious member of society, Magda astounds him by the vehemence of her gratitude for the part he has played in her life&quot; (Andrews, 1913 p 181).  

Keller “demands...that she shall permanently separate from their child… We have seen her ready to submit, to suffer abridgement of her personal freedom, even to relinquish her brilliant career, all for the sake of her old father, to whom she feels that she owes reparation. But now her maternal instincts rebel and when she reflects that such a heinous sacrifice is sanctioned by the general code of morals, she tramples that code into the dust” (Heller, 1905  pp 51-52). &quot;Hermann Sudermann has given to the world a new picture of modern womanhood, a type of free motherhood. As such the play is of great revolutionary significance, not alone to Germany, but to the universal spirit of a newer day...The colonel is a rigid military man. He is utterly blind to the modern conception of woman's place in life. He rules his family as the Kaiser rules the nation, with severe discipline, with terrorism and despotism. Magda rejects Keller's offer of marriage under his conditions, because 'she is outraged that she, the mother, who had given up everything for the sake of her child, who had slaved, struggled and drudged in order to win a career and economic independence- all for the sake of the child- that she should forswear her right to motherhood, her right to be true to herself!&quot; (Goldman, 1914 pp 78-79).

The play's &quot;main theme, now an old-fashioned one, [is] the struggle between the authority of a Biblical father and a rebellious daughter, who in the past has defied him by running away, and now urged by a sudden waft of homesickness, returns in triumph. She has had a bitter, hard struggle. She has known hunger; she has borne a son in loneliness and poverty to a man whom she presently meets again as a pillar of respectability under her father’s roof. Magda is the type of the [rebellious] woman of the ’eighties and ’nineties', a victorious example of 'self-realization'; she is one of the young released from the prison of 'Home' by Ibsen trumpets. But the walls of Jericho are now so flat that a modern audience has to make an effort of imagination, not unlike that demanded by a Greek play, in order to measure the strength of the bonds she has burst, or to believe in the passionate conviction with which her palsied old father still continues to assert his right to control her conscience and manner of life. Magda’s tirades, which once sent through us a thrill of fearful joy, now only prompt a mood of easy assent&quot; (MacCarthy, 1940 p 80).

In general, Sudermann's plays &quot;present to us, as 'Honor' does, the contrast between the provincial life and the big world. It shows us, as 'Sodom's end' does, the conflict between the quiet virtues of home and the brilliant temptations of art. It shows us, as 'The joy of living' does, the difference between fulfilling one's own personality and following the normal and narrow ideas of duty. Nor is that all; it does show us paternal authority, but that is only the German form taken by the constant difference between the older generation and the newer&quot; (Hale, 1905 p 71).

==&quot;Home&quot;==

[[File:Players_and_plays_of_the_last_quarter_century;_an_historical_summary_of_causes_and_a_critical_review_of_conditions_as_existing_in_the_American_theatre_at_the_close_of_the_nineteenth_century_(1903)_(14765610784).jpg|thumb|Magda, played by Mrs Patrick Campbell (1865-1940), wonders why she ever returned home. Illustration in &quot;Players and plays of the last quarter century&quot;, 1903, by Lewis Clinton  Strang (1869-1935)]]

Time: 1890s. Place: Germany.

Text at http://archive.org/details/magdaaplayinfour34184gut http://www.gutenberg.org/ebooks/34184 

Twelve years ago, Leopold Schwartze wanted his daughter, Magda, to marry Pastor Heffterdingt, but she refused. As a result, he angrily forbid her his house. After some difficult times as a small-time singer, Magda wrote back to her father, but the breach was complete. She eventually became a famous opera singer.  Now a retired army officer recovering from a stroke, Leopold learns from Franziska, his wife's sister, as well as the pastor, that she has been invited for a reception at the governor's house, but he refuses to see her. The pastor reprimands him. &quot;My dear colonel, I might ask, what speaks in you? A father's love? You could make no pretence to that. Your rights? I think rather it would be your right to rejoice in the good fortune of your child.&quot; At last, Leopold agrees to see her. On arriving, Madga is greeted by Franziska, her stepmother's sister, who assures her of her forgiveness, to which Magda responds sarcastically. Leopold takes it for granted that she will live in his house and intends to take her financial affairs in hand. When meeting the pastor after all this time, Magda admits she has always hated him for driving her away from home. But when the pastor mentions that he was the one mainly responsible for helping her father recover from his stroke, she softens and agrees to stay at home rather than a hotel. Augusta, her stepmother, and Franziska comment on Magda's expensive clothes, the latter most disagreeably. When Franziska sits with some importance to hear about her life, Magda sends her on her way to do something useful, which angers her considerably. Magda then learns from her younger sister, Marie, that she and her suitor cannot marry because Franziska, his aunt, refuses to give them the money they need. Magda generously offers Marie enough money to marry, to her joy and Franziska's disgust. On meeting some of her family's friends, Magda's opinions on several subjects rub them the wrong way, especially after hearing one woman express the sentiment that &quot;one must have one's real home&quot;. She answers: &quot;Why? One must have a vocation. That seems to me enough.&quot; Madga next meets Councillor Von Keller, a man who once made love to her and then abandoned her. He is astonished on learning that she had a son by him, to which she airily comments: &quot;Who are you? You're a strange man who gratified his lust and passed on with a laugh.&quot; Leopold begins to suspect something has happened between Keller and his daughter, but the former curtly replies to his searching questions: &quot;Pardon me, if you wish to know anything, I beg you to ask your daughter.&quot; When he does, Leopold learns the truth. On informing his daughter what he expects of her, he emphasizes that her refusal is likely to annul her sister's marriage plans: &quot;No one will marry a sister of yours,&quot; he assures her, to her distress. He marches out to discover Keller's intentions. Meanwhile, the pastor strongly reinforces his friend's views. She falters in growing agony but nevertheless blurts out: &quot;I will not, I will not. This house is not my home. My home is with my child.&quot; Leopold returns without having found him. He takes out a pistol-case and opens it, takes a pistol, cocks it with difficulty, examines the barrel, and aims at a point on the wall. His arm trembles violently. He strikes it angrily and lets the pistol drop. Keller returns, guessing that Leopold knows everything. He agrees to marry, but when alone with Magda, he high-handedly makes it known that he expects her to abandon her career and their son, at least till the lad grows of age when he can safely be adopted. Magda's entire being revolts at these suggestions. She wants to continue her career, to which Keller sarcastically responds: &quot;Shall I turn over your music, or take the tickets at the box-office?&quot; When Magda's father returns, he promises Keller he will force her if necessary to this marriage. To goad him out of his promise, she replies: &quot;Well, then, are you sure that you ought to force me on this man, that, according to your standards, I am altogether worthy of him? I mean- that he was the only one in my life?&quot; He feels for the pistol-case and takes the pistol out. &quot;You jade!&quot; he cries out, then falls stricken with a second stroke and dies. Bewildered, she wonders why she ever came home and whether she should stay. &quot;No one will hinder you from praying on his grave,&quot; the pastor answers laconically.

{{BookCat}}</text>
      <sha1>mlkmmujl0b5sbuszpabx15hlngfvj9m</sha1>
    </revision>
  </page>
  <page>
    <title>Devanagari/Ligatures</title>
    <ns>0</ns>
    <id>249576</id>
    <revision>
      <id>4657124</id>
      <parentid>4327515</parentid>
      <timestamp>2026-08-11T04:09:56Z</timestamp>
      <contributor>
        <username>~2026-44204-92</username>
        <id>3620626</id>
      </contributor>
      <comment>/* Ligatures */</comment>
      <origin>4657124</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="4186" sha1="1n3e6ae78iwzgl0q05vfpndv0uxa2ud" xml:space="preserve">==Ligatures==
{| border=&quot;2&quot; cellpadding=&quot;12&quot; cellspacing=&quot;12&quot; style=&quot;margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; font-size: 180%;&quot; 
!अ||आ||इ||ई||उ||ऊ||ऋ||ए||ऐ||ओ||औ||ऑ
|-
|&amp;nbsp;X||ा||ि||ी||ु||ू||ृ||े||ै||ो||ौ||ॉ
|-
!क
|का||कि||की||कु||कू||कृ||के||कै||को||कौ||कॉ
|-
!ख
|खा||खि||खी||खु||खू||खृ||खे||खै||खो||खौ||खॉ
|-
!ग
|गा||गि||गी||गु||गू||गृ||गे||गै||गो||गौ||गॉ
|-
!घ
|घा||घि||घी||घु||घू||घृ||घे||घै||घो||घौ||घॉ
|-
!च
|चा||चि||ची||चु||चू||चृ||चे||चै||चो||चौ||चॉ
|-
!छ
|छा||छि||छी||छु||छू||छृ||छे||छै||छो||छौ||छॉ
|-
!ज
|जा||जि||जी||जु||जू||जृ||जे||जै||जो||जौ||जॉ
|-
!ज़
|ज़ा||ज़ि||ज़ी||ज़ु||ज़ू||ज़ृ||ज़े||ज़ै||ज़ो||ज़ौ||ज़ॉ
|-
!झ
|झा||झि||झी||झु||झू||झृ||झे||झै||झो||झौ||झॉ
|-
!ञ
|ञा||ञि||ञी||ञु||ञू||ञृ||ञे||ञै||ञो||ञौ||ञॉ
|-
!ट
|टा||टि||टी||टु||टू||टृ||टे||टै||टो||टौ||टॉ
|-
!ठ
|ठा||ठि||ठी||ठु||ठू||ठृ||ठे||ठै||ठो||ठौ||ठॉ
|-
!ड
|डा||डि||डी||डु||डू||डृ||डे||डै||डो||डौ||डॉ
|-
!ड़
|ड़ा||ड़ि||ड़ी||ड़ु||ड़ू||ड़ृ||ड़े||ड़ै||ड़ो||ड़ौ||ड़ॉ
|-
!ढ
|ढा||ढि||ढी||ढु||ढू||ढृ||ढे||ढै||ढो||ढौ||ढॉ
|-
!ढ़
|ढ़ा||ढ़ि||ढ़ी||ढ़ु||ढ़ू||ढ़ृ||ढ़े||ढ़ै||ढ़ो||ढ़ौ||ढ़ॉ
|-
!ण
|णा||णि||णी||णु||णू||णृ||णे||णै||णो||णौ||णॉ
|-
!त
|ता||ति||ती||तु||तू||तृ||ते||तै||तो||तौ||तॉ
|-
!थ
|था||थि||थी||थु||थू||थृ||थे||थै||थो||थौ||थॉ
|-
!द
|दा||दि||दी||दु||दू||दृ||दे||दै||दो||दौ||दॉ
|-
!ध
|धा||धि||धी||धु||धू||धृ||धे||धै||धो||धौ||धॉ
|-
!न
|ना||नि||नी||नु||नू||नृ||ने||नै||नो||नौ||नॉ
|-
!प
|पा||पि||पी||पु||पू||पृ||पे||पै||पो||पौ||पॉ
|-
!फ
|फा||फि||फी||फु||फू||फृ||फे||फै||फो||फौ||फॉ
|-
!फ़
|फ़ा||फ़ि||फ़ी||फ़ु||फ़ू||फ़ृ||फ़े||फ़ै||फ़ो||फ़ौ||फ़ॉ
|-
!ब
|बा||बि||बी||बु||बू||बृ||बे||बै||बो||बौ||बॉ
|-
!भ
|भा||भि||भी||भु||भू||भृ||भे||भै||भो||भौ||भॉ
|-
!म
|मा||मि||मी||मु||मू||मृ||मे||मै||मो||मौ||मॉ
|-
!य
|या||यि||यी||यु||यू||यृ||ये||यै||यो||यौ||यॉ
|-
!य़
|य़ा||य़ि||य़ी||य़ु||य़ू||य़ृ||य़े||य़ै||य़ो||य़ौ||य़ॉ 
|-
!र
|रा||रि||री||रु||रू||रृ||रे||रै||रो||रौ||रॉ
|-
!ल
|ला||लि||ली||लु||लू||लृ||ले||लै||लो||लौ||लॉ
|-
!व
|वा||वि||वी||वु||वू||वृ||वे||वै||वो||वौ||वॉ
|-
!श
|शा||शि||शी||शु||शू||शृ||शे||शै||शो||शौ||शॉ
|-
!ष
|षा||षि||षी||षु||षू||षृ||षे||षै||षो||षौ||षॉ
|-
!स
|सा||सि||सी||सु||सू||सृ||से||सै||सो||सौ||सॉ
|-
!ह
|हा||हि||ही||हु||हू||हृ||हे||है||हो||हौ||हॉ
|-
!हॅ
|हाॅ||हिॅ||हीॅ||हुॅ||हूॅ||हृॅ||हेॅ||हैॅ||होॅ||हौॅ||हॅॉ
{{BookCat}}</text>
      <sha1>1n3e6ae78iwzgl0q05vfpndv0uxa2ud</sha1>
    </revision>
    <revision>
      <id>4657133</id>
      <parentid>4657124</parentid>
      <timestamp>2026-08-11T07:23:30Z</timestamp>
      <contributor>
        <username>ShakespeareFan00</username>
        <id>46022</id>
      </contributor>
      <minor />
      <origin>4657133</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="4189" sha1="7231tkmzfevc6avhj04dxwbkq6ci4je" xml:space="preserve">==Ligatures==
{| border=&quot;2&quot; cellpadding=&quot;12&quot; cellspacing=&quot;12&quot; style=&quot;margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; font-size: 180%;&quot; 
!अ||आ||इ||ई||उ||ऊ||ऋ||ए||ऐ||ओ||औ||ऑ
|-
|&amp;nbsp;X||ा||ि||ी||ु||ू||ृ||े||ै||ो||ौ||ॉ
|-
!क
|का||कि||की||कु||कू||कृ||के||कै||को||कौ||कॉ
|-
!ख
|खा||खि||खी||खु||खू||खृ||खे||खै||खो||खौ||खॉ
|-
!ग
|गा||गि||गी||गु||गू||गृ||गे||गै||गो||गौ||गॉ
|-
!घ
|घा||घि||घी||घु||घू||घृ||घे||घै||घो||घौ||घॉ
|-
!च
|चा||चि||ची||चु||चू||चृ||चे||चै||चो||चौ||चॉ
|-
!छ
|छा||छि||छी||छु||छू||छृ||छे||छै||छो||छौ||छॉ
|-
!ज
|जा||जि||जी||जु||जू||जृ||जे||जै||जो||जौ||जॉ
|-
!ज़
|ज़ा||ज़ि||ज़ी||ज़ु||ज़ू||ज़ृ||ज़े||ज़ै||ज़ो||ज़ौ||ज़ॉ
|-
!झ
|झा||झि||झी||झु||झू||झृ||झे||झै||झो||झौ||झॉ
|-
!ञ
|ञा||ञि||ञी||ञु||ञू||ञृ||ञे||ञै||ञो||ञौ||ञॉ
|-
!ट
|टा||टि||टी||टु||टू||टृ||टे||टै||टो||टौ||टॉ
|-
!ठ
|ठा||ठि||ठी||ठु||ठू||ठृ||ठे||ठै||ठो||ठौ||ठॉ
|-
!ड
|डा||डि||डी||डु||डू||डृ||डे||डै||डो||डौ||डॉ
|-
!ड़
|ड़ा||ड़ि||ड़ी||ड़ु||ड़ू||ड़ृ||ड़े||ड़ै||ड़ो||ड़ौ||ड़ॉ
|-
!ढ
|ढा||ढि||ढी||ढु||ढू||ढृ||ढे||ढै||ढो||ढौ||ढॉ
|-
!ढ़
|ढ़ा||ढ़ि||ढ़ी||ढ़ु||ढ़ू||ढ़ृ||ढ़े||ढ़ै||ढ़ो||ढ़ौ||ढ़ॉ
|-
!ण
|णा||णि||णी||णु||णू||णृ||णे||णै||णो||णौ||णॉ
|-
!त
|ता||ति||ती||तु||तू||तृ||ते||तै||तो||तौ||तॉ
|-
!थ
|था||थि||थी||थु||थू||थृ||थे||थै||थो||थौ||थॉ
|-
!द
|दा||दि||दी||दु||दू||दृ||दे||दै||दो||दौ||दॉ
|-
!ध
|धा||धि||धी||धु||धू||धृ||धे||धै||धो||धौ||धॉ
|-
!न
|ना||नि||नी||नु||नू||नृ||ने||नै||नो||नौ||नॉ
|-
!प
|पा||पि||पी||पु||पू||पृ||पे||पै||पो||पौ||पॉ
|-
!फ
|फा||फि||फी||फु||फू||फृ||फे||फै||फो||फौ||फॉ
|-
!फ़
|फ़ा||फ़ि||फ़ी||फ़ु||फ़ू||फ़ृ||फ़े||फ़ै||फ़ो||फ़ौ||फ़ॉ
|-
!ब
|बा||बि||बी||बु||बू||बृ||बे||बै||बो||बौ||बॉ
|-
!भ
|भा||भि||भी||भु||भू||भृ||भे||भै||भो||भौ||भॉ
|-
!म
|मा||मि||मी||मु||मू||मृ||मे||मै||मो||मौ||मॉ
|-
!य
|या||यि||यी||यु||यू||यृ||ये||यै||यो||यौ||यॉ
|-
!य़
|य़ा||य़ि||य़ी||य़ु||य़ू||य़ृ||य़े||य़ै||य़ो||य़ौ||य़ॉ 
|-
!र
|रा||रि||री||रु||रू||रृ||रे||रै||रो||रौ||रॉ
|-
!ल
|ला||लि||ली||लु||लू||लृ||ले||लै||लो||लौ||लॉ
|-
!व
|वा||वि||वी||वु||वू||वृ||वे||वै||वो||वौ||वॉ
|-
!श
|शा||शि||शी||शु||शू||शृ||शे||शै||शो||शौ||शॉ
|-
!ष
|षा||षि||षी||षु||षू||षृ||षे||षै||षो||षौ||षॉ
|-
!स
|सा||सि||सी||सु||सू||सृ||से||सै||सो||सौ||सॉ
|-
!ह
|हा||हि||ही||हु||हू||हृ||हे||है||हो||हौ||हॉ
|-
!हॅ
|हाॅ||हिॅ||हीॅ||हुॅ||हूॅ||हृॅ||हेॅ||हैॅ||होॅ||हौॅ||हॅॉ
|}
{{BookCat}}</text>
      <sha1>7231tkmzfevc6avhj04dxwbkq6ci4je</sha1>
    </revision>
  </page>
  <page>
    <title>Devanagari/Vowels</title>
    <ns>0</ns>
    <id>249578</id>
    <revision>
      <id>4657125</id>
      <parentid>4213094</parentid>
      <timestamp>2026-08-11T04:11:08Z</timestamp>
      <contributor>
        <username>~2026-44204-92</username>
        <id>3620626</id>
      </contributor>
      <comment>/* Vowels in alphabetical order */</comment>
      <origin>4657125</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1922" sha1="51zuydyegfkpdvt7d12v2k7ym4sk6yn" xml:space="preserve">These are the vowels in Devanagari: अ आ इ ई उ ऊ ॠ ॠ ऌ ॡ ए ऐ ओ औ ॳ अ

== Vowels (स्वर) ==
In Devanagari, vowels can be classified into five types:

#&lt;span style=&quot;font-size:large;&quot;&gt;ह्रस्व&lt;/span&gt; or short vowels
##&lt;span style=&quot;font-size:large;&quot;&gt;''अ''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;''इ''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;''उ''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;''ऋ''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;''ऌ''&lt;/span&gt;
#&lt;span style=&quot;font-size:large;&quot;&gt;दीर्घ&lt;/span&gt; or long vowels.
##&lt;span style=&quot;font-size:large;&quot;&gt;''आ''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;''ई''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;''ऊ''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;''ॠ''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;''ॡ''&lt;/span&gt;
#&lt;span style=&quot;font-size:large;&quot;&gt;संयुक्त&lt;/span&gt; or conjunct vowels.
##&lt;span style=&quot;font-size:large;&quot;&gt;अ&lt;/span&gt; + &lt;span style=&quot;font-size:large;&quot;&gt;इ&lt;/span&gt; = &lt;span style=&quot;font-size:large;&quot;&gt;''ए''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;अ&lt;/span&gt; + &lt;span style=&quot;font-size:large;&quot;&gt;ई&lt;/span&gt; = &lt;span style=&quot;font-size:large;&quot;&gt;''ऐ''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;अ&lt;/span&gt; + &lt;span style=&quot;font-size:large;&quot;&gt;उ&lt;/span&gt; = &lt;span style=&quot;font-size:large;&quot;&gt;''ओ''&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;अ&lt;/span&gt; + &lt;span style=&quot;font-size:large;&quot;&gt;ऊ&lt;/span&gt; = &lt;span style=&quot;font-size:large;&quot;&gt;''औ''&lt;/span&gt;
#&lt;span style=&quot;font-size:large;&quot;&gt;अनुनासिक&lt;/span&gt; or nasal vowels
##&lt;span style=&quot;font-size:large;&quot;&gt;''अं''&lt;/span&gt;
#&lt;span style=&quot;font-size:large;&quot;&gt;विसर्ग&lt;/span&gt;
##&lt;span style=&quot;font-size:large;&quot;&gt;''अः''&lt;/span&gt;

=== Vowels in alphabetical order ===
{| align=&quot;center&quot; rules=all style=&quot;text-align: center; border: 1px solid darkgray;&quot; cellpadding=10
|&lt;span style=&quot;font-size:x-large;&quot;&gt;अ आ इ ई उ ऊ ऋ ॠ ए ऐ ओ औ ऑ&lt;/span&gt;
|}

{{BookCat}}</text>
      <sha1>51zuydyegfkpdvt7d12v2k7ym4sk6yn</sha1>
    </revision>
  </page>
  <page>
    <title>Fighting/Martial Arts</title>
    <ns>0</ns>
    <id>263125</id>
    <revision>
      <id>4657111</id>
      <parentid>4436707</parentid>
      <timestamp>2026-08-10T22:54:41Z</timestamp>
      <contributor>
        <username>CommonsDelinker</username>
        <id>49843</id>
      </contributor>
      <comment>Removing [[:c:File:Lee_and_yip_chi_sau.jpg|Lee_and_yip_chi_sau.jpg]], it has been deleted from Commons by [[:c:User:Infrogmation|Infrogmation]] because: per [[:c:Commons:Deletion requests/File:Lee and yip chi sau.jpg|]].</comment>
      <origin>4657111</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="6650" sha1="f3azravf0tuj2dl5yksixqvac2yqxxa" xml:space="preserve">==Martial Arts==
[[File:Chris Stolzman teaching at Easton BJJ.jpg|180px|thumb|BJJ (Brazilian Ju Jitsu)]]
Martial Arts can be an excellent way to get in shape and learn some of the basics of defending yourself.  However, with the wrong kind of instruction it can ingrain some bad habits. You need to be very careful when selecting a Martial Art.  It can be prohibitively expensive, and while some martial arts offer a balanced and effective fighting program (such as [[wikipedia: Brazilian Jui-jitsu|Brazilian Jui-jitsu]]), others, such as many forms of internal [[wikipedia: Kung Fu|Kung Fu]] are questionable.  Many systems of Kung Fu have been watered down, and now solely concentrate on exercise and meditation programs, not on fighting/self-defense. Generally speaking, [[wikipedia: Jujitsu|Jujitsu]],  [[wikipedia: Wing Chun|Wing Chun]] Kung fu, [[wikipedia: Muay Thai|Muay Thai]], [[wikipedia: Eskrima|Eskrima]], [[wikipedia: Jeet Kune Do|Jeet Kune Do]], [[wikipedia:Silat|Silat]] and other reality based  martial arts would be the most effective.There are more options in the form of Egyptian Hikuta and Russian [[wikipedia: Systema|Systema]]. 
[[File:Taekwondo ITF Panambi.jpg|180px|thumb|TKD (Taekwondo)]]
[[File:Uki-goshi.jpg|180px|thumb|Judo]]
[[File:Toyama Kanken.jpg|180px|thumb|Karate]]
The following styles, generally speaking, focus on controlled sparring and specialize less on self-defense applications; styles such as [[w:Tae Kwon Do|Tae Kwon Do]], [[wikipedia: Judo|Judo]], Karate. There a few things to look for when selecting a martial arts program (Boxing) on merit of self-defense; If you see the class sparring, this is a good sign, particularly if the sparring is &quot;full contact&quot; - meaning, the exchange of blows are, while controlled, fairly heavy.  No dynamic stretching before a workout indicates either an inexperienced instructor, as stretching can prevent injuries, or a lighter-contact class, which can also be a sign of warning.  Also, look at the instructors; If they seem out of shape, or nonathletic, it could be a bad sign. You should also ask about the instructor's background in their training, lineage, style affiliation, etc.  Although it can be a marketing scheme, look for instructors with &quot;hands on&quot; experience with the subject, such as military/police experience, etc.  
Also it is good idea to train in different disciplines such as Jujitsu and full contact Karate which will  teach you both strikes as well as grappling techniques and counters. 
In real life encounters always grapple to strike and not the other way round.

[[File:Yoshimitsu Yamada Sensei.jpg|180px|thumb|Aikido]]
[[File:Yang-single (restoration).jpg|180px|thumb|Tai chi]]
Avoid Martial arts schools that employ complex flashy movements, such as high level kicks, or charge hefty fees for belts.  Although fees for belt testing is common, many are moving away from this system or eliminating the associated fees. Belts are actually a western construct, since traditionally there was only a master or student rank.  Street punks are not particularly concerned with belt rank, all they have on their mind is to rob, rape, or inflict harm to you.  On the street you are either the prey or the predator.

Warning: Be aware that training in a martial art carries a number of potential disadvantages.  The first disadvantage is that many martial artists have a false sense of security.  Most martial arts students (as well as their instructors) have never been in a real fight, and they train with fellow students, who do not attack them viciously.  Many martial arts instructors, in order to maintain their liability insurance, do not allow hard sparring or hard contact.  Therefore, many martial arts students have never been hit like they would in a real fight.  Be aware that being hit hard for the first time is a shock to the system.  I have seen high-ranking martial artists get beat down easily in real fights, because they went into shock after the first hit. 
----
However, the opposite is also true. I have seen well trained martial artists to take out a big fat guy with a single kick and the fellow landed up in hospital for a few weeks. So take hope, all is not lost. Take your martial arts training very seriously with special emphasis on self defense. One common mistake martial artists make is to get into a fighting stance which telegraphs their intentions. Another mistake is to wait for the other guy to strike first and then try to defend. Be aggressive and proactive with protecting yourself. It is better that ten men are wounded rather than you being killed. Be observant for movements of opponents and notice their shoulder-arm joint. With the slightest flicker you will know an attack is coming and then block and counter the attack as best as you can. Practice this several times in the dojo with a sparring partner.At first do this at slow speed and with a variety of punches at upper middle and lower level.Then do this at full speed sparring. Most schools also teach how to defend against kicks but in this case defending is easier as moving sideways and then blocking and countering is done with a little more time on your side.
-A martial arts student
----

Don't allow your training to give you a false sense of security.  Realize that most martial arts schools do not train students to fight for real.  Also, do not attempt to fight multiple opponents.  Despite what you see in movies, such as when Bruce Lee successfully fights up to 13 people at once or Christopher Nolan's Batman successfully engaging multiple firearm wielding thugs, if you attempt to fight more than one person at a time you will most probably get beaten down, no matter what color belt you possess. This is specially true when dealing with drunken violent sort of people because even if you hit them they often do not feel as much pain because of intoxication. In these cases it is better to avoid any altercation altogether until and unless they really threaten your life. The only way would be to kick them hard and fast at their groin or knees and run away quickly.

Do not allow your training to override good sense!

Always try to avoid fighting with anyone and try to dissuade violent and unreasonable people with calm and polite behavior. Do not give them any reason to be offended. Even if it is not your fault, apologize and move away from the spot. If this does not work threaten to call the police and send them to jail. Finally if all else fails then better run away while you still have the chance. If they grab and fight you then fight like a wildcat, use anything and everything you can to finish the fight.
{{BookCat}}</text>
      <sha1>f3azravf0tuj2dl5yksixqvac2yqxxa</sha1>
    </revision>
  </page>
  <page>
    <title>Aros/Platforms/Arm Raspberry Pi support</title>
    <ns>0</ns>
    <id>286123</id>
    <revision>
      <id>4657032</id>
      <parentid>4657014</parentid>
      <timestamp>2026-08-10T13:50:18Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657032</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79209" sha1="nu8n7d7mygbhluhe17f68j5pbsmby1a" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 GPU - 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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3 raspi-aarch64-system native 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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[ pi OS Lite] 

Other alternative OS 
*[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] 


==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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>nu8n7d7mygbhluhe17f68j5pbsmby1a</sha1>
    </revision>
    <revision>
      <id>4657033</id>
      <parentid>4657032</parentid>
      <timestamp>2026-08-10T13:50:43Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657033</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79225" sha1="8msc2fb51lrux642273a76t5oitu11j" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 GPU - 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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3 raspi-aarch64-system native 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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[ pi OS Lite] 

Other alternative lighter smaller OS 
*[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] 


==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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>8msc2fb51lrux642273a76t5oitu11j</sha1>
    </revision>
    <revision>
      <id>4657034</id>
      <parentid>4657033</parentid>
      <timestamp>2026-08-10T13:52:58Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657034</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79280" sha1="kyu6tn8w6vq8h83frwnx44uurlweztv" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 GPU - 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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3 raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[ pi OS Lite] 

Other alternative lighter smaller OS 
*[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] 


==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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>kyu6tn8w6vq8h83frwnx44uurlweztv</sha1>
    </revision>
    <revision>
      <id>4657035</id>
      <parentid>4657034</parentid>
      <timestamp>2026-08-10T13:59:06Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657035</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79363" sha1="7mgaa269lrc6sgj7ei401spdjuiydur" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 GPU - 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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3 raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>7mgaa269lrc6sgj7ei401spdjuiydur</sha1>
    </revision>
    <revision>
      <id>4657036</id>
      <parentid>4657035</parentid>
      <timestamp>2026-08-10T14:00:59Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657036</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79430" sha1="ku0lr8mjbu40e2bhjd18v2u4e6u686z" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 GPU - 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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3 raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>ku0lr8mjbu40e2bhjd18v2u4e6u686z</sha1>
    </revision>
    <revision>
      <id>4657037</id>
      <parentid>4657036</parentid>
      <timestamp>2026-08-10T14:08:15Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657037</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79434" sha1="ebehag1nvw6jepni93nra9rnfehz0gg" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 GPU - 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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>ebehag1nvw6jepni93nra9rnfehz0gg</sha1>
    </revision>
    <revision>
      <id>4657038</id>
      <parentid>4657037</parentid>
      <timestamp>2026-08-10T14:09:18Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657038</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79496" sha1="f233gxt62crz6r1xno8up83tkect805" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 GPU - 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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>f233gxt62crz6r1xno8up83tkect805</sha1>
    </revision>
    <revision>
      <id>4657039</id>
      <parentid>4657038</parentid>
      <timestamp>2026-08-10T14:14:19Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657039</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79496" sha1="2r9ditdj6e6e4vubfxcd59ybly4fcyu" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 GPU - 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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>2r9ditdj6e6e4vubfxcd59ybly4fcyu</sha1>
    </revision>
    <revision>
      <id>4657041</id>
      <parentid>4657039</parentid>
      <timestamp>2026-08-10T14:24:44Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657041</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79570" sha1="s90yr2ksr36ehl60cpo1kyg9k82ihhp" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 GPU - 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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>s90yr2ksr36ehl60cpo1kyg9k82ihhp</sha1>
    </revision>
    <revision>
      <id>4657042</id>
      <parentid>4657041</parentid>
      <timestamp>2026-08-10T14:32:00Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657042</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79571" sha1="3tbikv4x7p0v3kl58j3nx31fugwk2x6" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 GPU - 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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>3tbikv4x7p0v3kl58j3nx31fugwk2x6</sha1>
    </revision>
    <revision>
      <id>4657043</id>
      <parentid>4657042</parentid>
      <timestamp>2026-08-10T14:33:18Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657043</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79583" sha1="pbcthr1z4a7avhcwv5hwt6xox8l6sjp" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
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 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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>pbcthr1z4a7avhcwv5hwt6xox8l6sjp</sha1>
    </revision>
    <revision>
      <id>4657044</id>
      <parentid>4657043</parentid>
      <timestamp>2026-08-10T14:33:59Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657044</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79583" sha1="h4ywja79verua00m4hrhroxkouk3c8g" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 Over four million first gen pis sold  

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 
2015 Pi Zero BCM2835 released 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>h4ywja79verua00m4hrhroxkouk3c8g</sha1>
    </revision>
    <revision>
      <id>4657045</id>
      <parentid>4657044</parentid>
      <timestamp>2026-08-10T14:34:24Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657045</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79583" sha1="c4u0duvho4x5c8kdym6c63i2rxafahg" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 Over four million first gen pis sold  
2015 Pi Zero BCM2835 released 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>c4u0duvho4x5c8kdym6c63i2rxafahg</sha1>
    </revision>
    <revision>
      <id>4657046</id>
      <parentid>4657045</parentid>
      <timestamp>2026-08-10T14:37:10Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657046</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79582" sha1="mj6stjk8wt362hmsck7sdllcpnonrh4" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 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 Over four million first gen pis sold  
2015 Pi Zero BCM2835 released 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>mj6stjk8wt362hmsck7sdllcpnonrh4</sha1>
    </revision>
    <revision>
      <id>4657047</id>
      <parentid>4657046</parentid>
      <timestamp>2026-08-10T14:43:55Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657047</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79595" sha1="94f3x8hbxak66w5i3gomp8czp12lzhk" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 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 Over four million first gen pis sold  
2015 Pi Zero BCM2835 released 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 underclocked 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>94f3x8hbxak66w5i3gomp8czp12lzhk</sha1>
    </revision>
    <revision>
      <id>4657048</id>
      <parentid>4657047</parentid>
      <timestamp>2026-08-10T14:44:37Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657048</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79605" sha1="rolt3fo6zkg1vw2i3kyyzd15xgh8a8v" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 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 Over four million first gen pis sold  
2015 Pi Zero BCM2835 released 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 underclocked to 900Mhz 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>rolt3fo6zkg1vw2i3kyyzd15xgh8a8v</sha1>
    </revision>
    <revision>
      <id>4657049</id>
      <parentid>4657048</parentid>
      <timestamp>2026-08-10T14:56:44Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657049</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79677" sha1="jqx1jkm4280pm3dedthars6og95gy26" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 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 Over four million first gen pis sold  
2015 Pi Zero BCM2835 released 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 underclocked to 900Mhz 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version. Any issues booting could be down to the SD card so please use another. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>jqx1jkm4280pm3dedthars6og95gy26</sha1>
    </revision>
    <revision>
      <id>4657050</id>
      <parentid>4657049</parentid>
      <timestamp>2026-08-10T14:57:08Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657050</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79680" sha1="20qzcx47bo0ip19mjgv0ae7671v9s1x" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 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 Over four million first gen pis sold  
2015 Pi Zero BCM2835 released 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 underclocked to 900Mhz 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>20qzcx47bo0ip19mjgv0ae7671v9s1x</sha1>
    </revision>
    <revision>
      <id>4657051</id>
      <parentid>4657050</parentid>
      <timestamp>2026-08-10T14:58:10Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657051</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79684" sha1="24spq9bad8f91zb5yfndnmoq0qyxwls" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 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 Over four million first gen pis sold  
2015 Pi Zero BCM2835 released 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 underclocked to 900Mhz 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>24spq9bad8f91zb5yfndnmoq0qyxwls</sha1>
    </revision>
    <revision>
      <id>4657053</id>
      <parentid>4657051</parentid>
      <timestamp>2026-08-10T15:22:53Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657053</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79773" sha1="ea1ejt0x5k2ui9whwcwj18wsux40fkc" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 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 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W 1GHz, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 underclocked to 900Mhz 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>ea1ejt0x5k2ui9whwcwj18wsux40fkc</sha1>
    </revision>
    <revision>
      <id>4657054</id>
      <parentid>4657053</parentid>
      <timestamp>2026-08-10T15:25:03Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657054</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79798" sha1="4s3hrzuhu8z1n103fuk2c5y0fa15s1t" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 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 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 underclocked to 900Mhz 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A 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 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>4s3hrzuhu8z1n103fuk2c5y0fa15s1t</sha1>
    </revision>
    <revision>
      <id>4657055</id>
      <parentid>4657054</parentid>
      <timestamp>2026-08-10T15:28:02Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657055</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79838" sha1="k2whyesph4hygqj2c7b2yrfoq72vfcd" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 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 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 underclocked to 900Mhz 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2019 Pi 4 Model 2B - BCM2712 4 usb 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

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 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>k2whyesph4hygqj2c7b2yrfoq72vfcd</sha1>
    </revision>
    <revision>
      <id>4657057</id>
      <parentid>4657055</parentid>
      <timestamp>2026-08-10T15:31:13Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657057</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79929" sha1="pjgbn1z8xth3jy0jt7h7sc6lx7ennz2" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 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 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 cores, and 2core open-hardware Hazard3 RISC-V cores 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 underclocked to 900Mhz 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2019 Pi 4 Model 2B - BCM2712 4 usb 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>pjgbn1z8xth3jy0jt7h7sc6lx7ennz2</sha1>
    </revision>
    <revision>
      <id>4657058</id>
      <parentid>4657057</parentid>
      <timestamp>2026-08-10T15:34:24Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657058</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79919" sha1="fecxl4eqosaelvdxtuco8dgdfuf2sip" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 cores, and 2core open-hardware Hazard3 RISC-V cores 

2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837 underclocked to 900Mhz 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2019 Pi 4 Model 2B - BCM2712 4 usb 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>fecxl4eqosaelvdxtuco8dgdfuf2sip</sha1>
    </revision>
    <revision>
      <id>4657059</id>
      <parentid>4657058</parentid>
      <timestamp>2026-08-10T15:40:32Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657059</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79972" sha1="4wakupp24c3jv5lm9utkz7jk39ghw2c" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 cores, and 2core open-hardware Hazard3 RISC-V cores 

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with throttling and reduced heat 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2019 Pi 4 Model 2B - BCM2712 4 usb 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>4wakupp24c3jv5lm9utkz7jk39ghw2c</sha1>
    </revision>
    <revision>
      <id>4657061</id>
      <parentid>4657059</parentid>
      <timestamp>2026-08-10T15:45:58Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657061</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79956" sha1="1nch30qsrpxpedkscgv3ohsydcy5wju" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 cores, and 2core open-hardware Hazard3 RISC-V cores 

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2019 Pi 4 Model 2B - BCM2712 4 usb 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>1nch30qsrpxpedkscgv3ohsydcy5wju</sha1>
    </revision>
    <revision>
      <id>4657068</id>
      <parentid>4657061</parentid>
      <timestamp>2026-08-10T16:14:25Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657068</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79961" sha1="h3vddnolgpth3td02ep4o43snt7vcx1" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 cores, and 2core open-hardware Hazard3 RISC-V cores 

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2019 Pi 4 Model 2B - BCM2712 4 usb 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>h3vddnolgpth3td02ep4o43snt7vcx1</sha1>
    </revision>
    <revision>
      <id>4657072</id>
      <parentid>4657068</parentid>
      <timestamp>2026-08-10T16:20:36Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657072</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79949" sha1="mezf1bckyrlks2rfvn3ddq69jdfao0r" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2019 Pi 4 Model 2B - BCM2712 4 usb 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>mezf1bckyrlks2rfvn3ddq69jdfao0r</sha1>
    </revision>
    <revision>
      <id>4657073</id>
      <parentid>4657072</parentid>
      <timestamp>2026-08-10T16:23:33Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657073</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79913" sha1="112sbvdy3z341rnrnnmvig1eg98q2z8" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>112sbvdy3z341rnrnnmvig1eg98q2z8</sha1>
    </revision>
    <revision>
      <id>4657074</id>
      <parentid>4657073</parentid>
      <timestamp>2026-08-10T16:31:01Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657074</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79953" sha1="kz123n8kcrrgbkx0xk0yz1kywii4bqe" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>kz123n8kcrrgbkx0xk0yz1kywii4bqe</sha1>
    </revision>
    <revision>
      <id>4657075</id>
      <parentid>4657074</parentid>
      <timestamp>2026-08-10T16:32:20Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657075</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79960" sha1="aqjkc1aa8gj29kl6jlnjqneumq5ak2z" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.2 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>aqjkc1aa8gj29kl6jlnjqneumq5ak2z</sha1>
    </revision>
    <revision>
      <id>4657076</id>
      <parentid>4657075</parentid>
      <timestamp>2026-08-10T16:35:11Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657076</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79960" sha1="212mi8hvub7my84c7wgr4misapjkf9x" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 and vulkan 1.1 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>212mi8hvub7my84c7wgr4misapjkf9x</sha1>
    </revision>
    <revision>
      <id>4657078</id>
      <parentid>4657076</parentid>
      <timestamp>2026-08-10T16:36:59Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657078</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79951" sha1="f425qj5ftaeycub8atac0msqidd51rs" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>f425qj5ftaeycub8atac0msqidd51rs</sha1>
    </revision>
    <revision>
      <id>4657081</id>
      <parentid>4657078</parentid>
      <timestamp>2026-08-10T16:53:19Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657081</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80001" sha1="gdxg1752dymy34kdznr53bhpne19ka8" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>gdxg1752dymy34kdznr53bhpne19ka8</sha1>
    </revision>
    <revision>
      <id>4657088</id>
      <parentid>4657081</parentid>
      <timestamp>2026-08-10T19:20:48Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657088</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80050" sha1="m1o0wg0brth83y9m5g1uilc0xftkmqc" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with 32bit RP2040 32-bit 2Core ARM Cortex-M0+ - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>m1o0wg0brth83y9m5g1uilc0xftkmqc</sha1>
    </revision>
    <revision>
      <id>4657089</id>
      <parentid>4657088</parentid>
      <timestamp>2026-08-10T19:22:16Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657089</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80058" sha1="ahyfer3ccc8ptoo0ilvxg3hvkuyha7t" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 

2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 

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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>ahyfer3ccc8ptoo0ilvxg3hvkuyha7t</sha1>
    </revision>
    <revision>
      <id>4657094</id>
      <parentid>4657089</parentid>
      <timestamp>2026-08-10T20:04:53Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657094</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80060" sha1="6t0awfrgotqlf93bo3ufbnum3rr4ujt" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2017 Raspberry Pi Compute Module 3 CM3 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>6t0awfrgotqlf93bo3ufbnum3rr4ujt</sha1>
    </revision>
    <revision>
      <id>4657095</id>
      <parentid>4657094</parentid>
      <timestamp>2026-08-10T20:07:52Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657095</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79954" sha1="4pkhxnb0dejuf08wvner22ifhb689nn" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2016 Compute 3 CM3 launched BCM2837B0 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>4pkhxnb0dejuf08wvner22ifhb689nn</sha1>
    </revision>
    <revision>
      <id>4657096</id>
      <parentid>4657095</parentid>
      <timestamp>2026-08-10T20:09:07Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657096</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79954" sha1="srifh3g1wpheitw2tma348tuyl0sj7v" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2017 Compute 3 CM3 launched BCM2837B0 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>srifh3g1wpheitw2tma348tuyl0sj7v</sha1>
    </revision>
    <revision>
      <id>4657097</id>
      <parentid>4657096</parentid>
      <timestamp>2026-08-10T20:10:54Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657097</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79964" sha1="82omi6uglymczy1h5utqzmgofn6a3z4" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>82omi6uglymczy1h5utqzmgofn6a3z4</sha1>
    </revision>
    <revision>
      <id>4657098</id>
      <parentid>4657097</parentid>
      <timestamp>2026-08-10T20:12:50Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657098</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79976" sha1="8dzawyakl6by8j8j697oad69hor6cmn" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 single core builds start 
2026 August Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>8dzawyakl6by8j8j697oad69hor6cmn</sha1>
    </revision>
    <revision>
      <id>4657099</id>
      <parentid>4657098</parentid>
      <timestamp>2026-08-10T20:16:15Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657099</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79993" sha1="7b8i0owr8s2gyy4jjqkzuwljn5z8wc7" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 single core builds start 
2026 August Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>7b8i0owr8s2gyy4jjqkzuwljn5z8wc7</sha1>
    </revision>
    <revision>
      <id>4657100</id>
      <parentid>4657099</parentid>
      <timestamp>2026-08-10T20:16:45Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657100</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79981" sha1="5nmcbqmjyxt2ajzcm01fkq74tmnl203" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A or 2A with single core 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>5nmcbqmjyxt2ajzcm01fkq74tmnl203</sha1>
    </revision>
    <revision>
      <id>4657128</id>
      <parentid>4657100</parentid>
      <timestamp>2026-08-11T07:14:12Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657128</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79958" sha1="rywm3mg6jp8zknbdpwlqovur6xf1yy5" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 RP3A0 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>rywm3mg6jp8zknbdpwlqovur6xf1yy5</sha1>
    </revision>
    <revision>
      <id>4657129</id>
      <parentid>4657128</parentid>
      <timestamp>2026-08-11T07:15:54Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657129</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="79958" sha1="6mhvbn1k245ee3vy3mwg0fxfky3w8zg" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w RP3A0 quad 1GHz Cortex-A53 64bit BCM2710A1 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board  
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 with optional IO board 
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>6mhvbn1k245ee3vy3mwg0fxfky3w8zg</sha1>
    </revision>
    <revision>
      <id>4657147</id>
      <parentid>4657129</parentid>
      <timestamp>2026-08-11T08:58:47Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <comment>8Gb 16Gb eMMc</comment>
      <origin>4657147</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80284" sha1="i2npxd6wfr8ocp23ur062rn19k864bo" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w RP3A0 quad 1GHz Cortex-A53 64bit BCM2710A1 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board 
     CM4104000 4GB RAM Lite 
     CM4004008-4GB-RAM 8GB-EMMC SOM 
     CM4104032 4GB RAM 32GB emmc 
     CM4108000 8GB RAM Lite 
     CM4008016 8GB RAM 16Gb eMMc
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 
     CM4S01008 Raspberry Pi SC0763 Compute Module 4S CM4S, 1GB SDRAM, 8GB eMMC Flash

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 BCM2712 55mm x 40mm form factor with optional IO board 
     CM5004000 Compute Module CM5 4GB RAM 0GB eMMC Lite
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>i2npxd6wfr8ocp23ur062rn19k864bo</sha1>
    </revision>
    <revision>
      <id>4657148</id>
      <parentid>4657147</parentid>
      <timestamp>2026-08-11T09:01:12Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657148</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80375" sha1="3zy7ulvamdefw1asticyhsg26gu64hy" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w RP3A0 quad 1GHz Cortex-A53 64bit BCM2710A1 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board 
     CM4102000 2GB RAM Lite 
     CM4104000 4GB RAM Lite 
     CM4004008-4GB-RAM 8GB-EMMC SOM 
     CM4104032 4GB RAM 32GB emmc 
     CM4108000 8GB RAM Lite 
     CM4008016 8GB RAM 16Gb eMMc
2021 Pi4 CM4S with ddr2 sodimm pinouts but not electrically same 
     CM4S01008 Raspberry Pi SC0763 Compute Module 4S CM4S, 1GB SDRAM, 8GB eMMC Flash

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 CM5 BCM2712 55mm x 40mm form factor with optional IO board 
     CM5004000 04GB RAM 0GB eMMC Lite
     CM5008000 08GB RAM 0GB eMMC Lite
     CM5016000 16GB RAM 0GB eMMC Lite
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>3zy7ulvamdefw1asticyhsg26gu64hy</sha1>
    </revision>
    <revision>
      <id>4657149</id>
      <parentid>4657148</parentid>
      <timestamp>2026-08-11T09:03:31Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657149</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80450" sha1="ao3ujsf2hqn7r9c8g2joq1g4dxaf5xn" xml:space="preserve">{{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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w RP3A0 quad 1GHz Cortex-A53 64bit BCM2710A1 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board 
     CM4102000 2GB RAM Lite 
     CM4104000 4GB RAM Lite 
     CM4004008-4GB-RAM 8GB-EMMC SOM 
     CM4104032 4GB RAM 32GB emmc 
     CM4108000 8GB RAM Lite 
     CM4008016 8GB RAM 16Gb eMMc
2021 Raspberry Pi SC0763 Compute Module 4S CM4S with ddr2 sodimm pinouts but not electrically the same 
     CM4S01000 1GB RAM Lite
     CM4S01008 1GB RAM 8GB eMMC Flash
     CM4S02000 2GB RAM Lite
     CM4S04000 4GB RAM Lite

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 CM5 BCM2712 55mm x 40mm form factor with optional IO board 
     CM5004000 04GB RAM 0GB eMMC Lite
     CM5008000 08GB RAM 0GB eMMC Lite
     CM5016000 16GB RAM 0GB eMMC Lite
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>ao3ujsf2hqn7r9c8g2joq1g4dxaf5xn</sha1>
    </revision>
    <revision>
      <id>4657150</id>
      <parentid>4657149</parentid>
      <timestamp>2026-08-11T09:05:01Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657150</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80466" sha1="dq3i6kesm8sibf45r12xckhvtulwlbk" xml:space="preserve">{{ArosNav}}

[[#Native]]

[[#Hosted]]

[[#Hardware]]


==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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w RP3A0 quad 1GHz Cortex-A53 64bit BCM2710A1 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board 
     CM4102000 2GB RAM Lite 
     CM4104000 4GB RAM Lite 
     CM4004008-4GB-RAM 8GB-EMMC SOM 
     CM4104032 4GB RAM 32GB emmc 
     CM4108000 8GB RAM Lite 
     CM4008016 8GB RAM 16Gb eMMc
2021 Raspberry Pi SC0763 Compute Module 4S CM4S with ddr2 sodimm pinouts but not electrically the same 
     CM4S01000 1GB RAM Lite
     CM4S01008 1GB RAM 8GB eMMC Flash
     CM4S02000 2GB RAM Lite
     CM4S04000 4GB RAM Lite

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 CM5 BCM2712 55mm x 40mm form factor with optional IO board 
     CM5004000 04GB RAM 0GB eMMC Lite
     CM5008000 08GB RAM 0GB eMMC Lite
     CM5016000 16GB RAM 0GB eMMC Lite
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>dq3i6kesm8sibf45r12xckhvtulwlbk</sha1>
    </revision>
    <revision>
      <id>4657151</id>
      <parentid>4657150</parentid>
      <timestamp>2026-08-11T09:07:53Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657151</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80501" sha1="6tij7rxq6xqnabiitadeuers039xp7o" xml:space="preserve">{{ArosNav}}

[[#Native]]

[[#Hosted]]

[[#Hardware]]


==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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w RP3A0 quad 1GHz Cortex-A53 64bit BCM2710A1 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board 
     CM4102000 2GB RAM Lite 
     CM4104000 4GB RAM Lite 
     CM4004008-4GB-RAM 8GB-EMMC SOM 
     CM4104032 4GB RAM 32GB emmc 
     CM4108000 8GB RAM Lite 
     CM4008016 8GB RAM 16Gb eMMc
2021 Raspberry Pi SC0763 Compute Module 4S CM4S with ddr2 sodimm pinouts but not electrically the same 
     CM4S01000 1GB RAM Lite
     CM4S01008 1GB RAM 8GB eMMC Flash
     CM4S02000 2GB RAM Lite
     CM4S04000 4GB RAM Lite

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 CM5 BCM2712 55mm x 40mm form factor with optional IO board 
     CM5004000 04GB RAM 0GB eMMC Lite
     CM5008000 08GB RAM 0GB eMMC Lite
     CM5016000 16GB RAM 0GB eMMC Lite
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.

Dual VDP and scalable QPU in VC4 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>6tij7rxq6xqnabiitadeuers039xp7o</sha1>
    </revision>
    <revision>
      <id>4657152</id>
      <parentid>4657151</parentid>
      <timestamp>2026-08-11T09:10:38Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657152</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80529" sha1="kotcjlp9x9i8xe0hh2w8qpxaqw5msub" xml:space="preserve">{{ArosNav}}

[[#Native]]

[[#Hosted]]

[[#Hardware]]


==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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w RP3A0 quad 1GHz Cortex-A53 64bit BCM2710A1 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board 
     CM4102000 2GB RAM Lite 
     CM4104000 4GB RAM Lite 
     CM4004008-4GB-RAM 8GB-EMMC SOM 
     CM4104032 4GB RAM 32GB emmc 
     CM4108000 8GB RAM Lite 
     CM4008016 8GB RAM 16Gb eMMc
2021 Raspberry Pi SC0763 Compute Module 4S CM4S with ddr2 sodimm pinouts but not electrically the same 
     CM4S01000 1GB RAM Lite
     CM4S01008 1GB RAM 8GB eMMC Flash
     CM4S02000 2GB RAM Lite
     CM4S04000 4GB RAM Lite
     CM4S08000 8GB RAM Lite

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 CM5 BCM2712 55mm x 40mm form factor with optional IO board 
     CM5004000 04GB RAM 0GB eMMC Lite
     CM5008000 08GB RAM 0GB eMMC Lite
     CM5016000 16GB RAM 0GB eMMC Lite
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.

Dual VDP and scalable QPU in VC4 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>kotcjlp9x9i8xe0hh2w8qpxaqw5msub</sha1>
    </revision>
    <revision>
      <id>4657153</id>
      <parentid>4657152</parentid>
      <timestamp>2026-08-11T09:44:30Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657153</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80566" sha1="is0srawi03j45ra9q39sy36juwglu3v" xml:space="preserve">{{ArosNav}}

[[#Native]]

[[#Hosted]]

[[#Hardware]]


==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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible - beware of the I2C protocol issue - 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w RP3A0 quad 1GHz Cortex-A53 64bit BCM2710A1 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board 
     CM4102000 2GB RAM Lite 
     CM4104000 4GB RAM Lite 
     CM4004008-4GB-RAM 8GB-EMMC SOM 
     CM4104032 4GB RAM 32GB emmc 
     CM4108000 8GB RAM Lite 
     CM4008016 8GB RAM 16Gb eMMc
2021 Raspberry Pi SC0763 Compute Module 4S CM4S with ddr2 sodimm pinouts but not electrically the same 
     CM4S01000 1GB RAM Lite
     CM4S01008 1GB RAM 8GB eMMC Flash
     CM4S02000 2GB RAM Lite
     CM4S04000 4GB RAM Lite
     CM4S08000 8GB RAM Lite

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 CM5 BCM2712 55mm x 40mm form factor with optional IO board 
     CM5004000 04GB RAM 0GB eMMC Lite
     CM5008000 08GB RAM 0GB eMMC Lite
     CM5016000 16GB RAM 0GB eMMC Lite
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.

Dual VDP and scalable QPU in VC4 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>is0srawi03j45ra9q39sy36juwglu3v</sha1>
    </revision>
    <revision>
      <id>4657155</id>
      <parentid>4657153</parentid>
      <timestamp>2026-08-11T10:17:53Z</timestamp>
      <contributor>
        <username>Jeff1138</username>
        <id>301139</id>
      </contributor>
      <minor />
      <origin>4657155</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="80573" sha1="iksf8m5lkxvlrzcyifl5c2he72ss5av" xml:space="preserve">{{ArosNav}}

[[#Native]]

[[#Hosted]]

[[#Hardware]]


==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 &quot;promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.&quot;

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 &quot;southbridge&quot; 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

&lt;pre&gt;
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 
2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 
2015 Over four million first gen pis sold  
2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 
2016 Pi0 1.3 released with camera csi connector 
2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 
2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 
2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware Hazard3 RISC-V  

2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - 
2015 Over a million pi2s sold 


2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 
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 - 5V 2.5A 
2016 PIs total over 10 million worldwide 
2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage on small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible - beware of the I2C protocol issue - 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 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 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 
2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0 1.2Ghz, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC on not electrically DDR2 sodimm factor 
2021 Pi zero 2 w RP3A0 quad 1GHz Cortex-A53 64bit BCM2710A1 512mB SDRam 


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 5V 3A power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2020 Raspberry Pi Compute Module 4 BCM2711 on new 55mm x 40mm form factor with optional breakout IO board 
     CM4102000 2GB RAM Lite 
     CM4104000 4GB RAM Lite 
     CM4004008-4GB-RAM 8GB-EMMC SOM 
     CM4104032 4GB RAM 32GB emmc 
     CM4108000 8GB RAM Lite 
     CM4008016 8GB RAM 16Gb eMMc
2021 Raspberry Pi SC0763 Compute Module 4S CM4S with ddr2 sodimm pinouts but not electrically the same 
     CM4S01000 1GB RAM Lite
     CM4S01008 1GB RAM 8GB eMMC Flash
     CM4S02000 2GB RAM Lite
     CM4S04000 4GB RAM Lite
     CM4S08000 8GB RAM Lite

2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu 
2024 Pi 5 2GB version uses BCM2712D0 
2024 Pi-500 
2024 Raspberry Pi Compute Module 5 CM5 BCM2712 55mm x 40mm form factor with optional IO board 
     CM5004000 04GB RAM 0GB eMMC Lite
     CM5008000 08GB RAM 0GB eMMC Lite
     CM5016000 16GB RAM 0GB eMMC Lite
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 Pi 4, 5 and 500 DTBs added, 
2026 
2027 

2028 Pi 6 
&lt;/pre&gt;


===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]


[https://aros.sourceforge.io/nightly1.html RaspberryPi 3, 3+ raspi-aarch64-system native 64bit ArmV8 builds] can be unbz2'd and copied to fat32 formatted micro sd card 

64bit works well on a single core and is more complete than the old 32bit version. Any issues booting could be down to the SD card so please use another SD. 


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===

On latest Apple Silicon [https://github.com/jonx/AROS-AArch64/releases early buggy alpha version of hosted Aros .dmg on MacOS12+] 
AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port 

[http://www.aros.org/snapshots1.html old linux and android hosted 32bit] 


===Good sites to visit===

*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] 

Linux only
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build] 
*[https://dietpi.com/ DietPi]
*[http://www.tinycorelinux.net/ports.html piCore]
*[https://www.raspberrypi.com/software/operating-systems/ pi OS Lite] 

Other alternative lighter smaller OS 
*[https://aros.sourceforge.io/nightly1.html Aros 64bit ARMV8 single core] 
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k for amiga computers] 


*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 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 -:

&lt;pre&gt;
&gt;cd /build/aros-raspi-armhf
&gt;/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
&gt;make
&gt;make arosboot-raspi
&lt;/pre&gt;

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 ..
&lt;pre&gt;
./configure --target=raspi-armhf
make arosboot-raspi
&lt;/pre&gt;

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 &quot;emulation&quot; 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 ====

=====64bit=====


[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]


=====32bit=====

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 &quot;android&quot; 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:

&lt;pre&gt;
enum test {foo, bar};
enum test testvar;
&lt;/pre&gt;

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  &lt;your_os_includes&gt;  -isystem  &lt;host_OS_gcc_private_includes&gt;
 -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 &quot;./configure --target=raspi-armhf&quot; is enough to start, then &quot;make arosboot-raspi&quot; 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 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armel' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
&lt;/pre&gt;

&lt;pre&gt;
 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include
&lt;/pre&gt;

Cross-compiling Ubuntu ARM hard-float 
&lt;pre&gt;
    sudo sh
    echo 'foreign-architecture armhf' &gt;&gt;/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' &gt;/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
&lt;/pre&gt;

&lt;pre&gt;
    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include
&lt;/pre&gt;

Now, the AROS build is configured properly and all you need to do is:

 make


== Hardware ==

===64bit===


====BCM2712====

With the Pi5 

Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the [https://lore.kernel.org/dri-devel/20230928114532.167854-1-itoral@igalia.com/ open-source V3D driver] stack within [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450 Mesa] opefully be merged for Mesa 23.3 


====BCM2711====

With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 

*[https://github.com/axizo-pi/V3DLib vc6 V3D 4.2] is derived from [https://docs.broadcom.com/doc/12358545 vc4], but it is significantly different 
The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles.
The instruction encoding for the QPUs is different, but the core instructions are the same.

Instructions for packed 8 bit int math has been dropped, along with most of the pack modes.
Instructions for packed 16bit float math has been added (2 floats at in a single operation)
With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register.

the multiply ALU can now fadd, so you can issue two fadds per instruction.
    the add ALU has gained a bunch of new instructions 

    the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of &quot;one read port, one write port&quot; to one &quot;two read ports, one write port&quot; block)

    The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhz
    But it looks like a lot of effort has been put putting those theoretical FLOPs to better use.
    vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers.
    vc5 added a four thread per QPU mode, with 16 registers per thread.
    vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads.
    With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests.

    Most of the design changes have gone to improving the fixed function hardware around the QPUs.
    a fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible 
    The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer)
    Faster LPDDR4 memory.
    A MMU, allowing a much simpler/faster kernel driver.
    Many more texture formats, framebuffer formats.
    All the features needed for opengl es 3.0 

H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates 

Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs
If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised 

Possible maximum performance 
&lt;pre&gt;
VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s
VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s
VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
&lt;/pre&gt;


====BCM2837==== 

With the Pi3 
* Broadcom BCM43438 chip provides 2.4&amp;nbsp;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] 

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.

Dual VDP and scalable QPU in VC4 


===32bit===

=== Core Kernel ===


====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700&amp;nbsp;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&amp;view=article&amp;id=106:rasperry-pi-usb-controller&amp;catid=45:raspberry-pi&amp;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

*[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 &quot;rom&quot; 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 &quot;OR&quot; 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 &quot;virtual&quot; 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 &quot;bcmdma.resource&quot; 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 &quot;blitting&quot;. 
# [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 typical for most other OSs before a lot of open sourcing i.e. around 2017 

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 &quot;kernel.img&quot; 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 

&lt;pre&gt;
?          - 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
&lt;/pre&gt;

Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,

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 &quot;Hardware IRQ number X, whatever this means&quot;. 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 &quot;abstract timer interrupt&quot;, 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. 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 &quot;Poseidon Event Task&quot; during RTF_COLDSTART -&gt; 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 &quot;fake&quot; 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 ===

VCore developed by Alphamosaic Ltd and now owned by Broadcom. 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 &quot;TODO: lookup optimal mmu table settings for raspi memory&quot;
        /* Set up an identity-mapping for all 4GB */
        for(x = 0; x &lt; 4096; x ++)
        {
            pagetable[x] = x&lt;&lt;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&lt;&lt;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=&gt;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 &quot;external memory allocators&quot;. 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 &quot;#define DEBUG 1&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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) -&gt; so surely it should be capable of then rendeing into it? I don't actually create the framebuffer &quot;bitmap object&quot; 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.

&lt;pre&gt;
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
&lt;/pre&gt;

It should likely be vHidd_StdPixFmt_RGB16_LE

This stuff is a bit confusing.  The &quot;names&quot; 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-&gt;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 (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (-&gt;entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)

0xAA,0xRR,0xGG,0xBB on big endian (-&gt;entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (-&gt;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 .
 
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 &amp; 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.

vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. 

 Framebuffer - basic display 

RasPi has to speak to the &quot;operating system&quot; 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 &quot;interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer.&quot; 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 &quot;virtual&quot; 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 &quot;prefixed&quot; 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 &amp; 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 
&lt;pre&gt;
Section &quot;Screen&quot;
Identifier &quot;Default Screen&quot;
DefaultDepth 16
SubSection &quot;Display&quot;
# Viewport 0 0
Depth 16
Modes &quot;800x600&quot;
EndSubsection
EndSection
Section &quot;Device&quot;
Option &quot;Backingstore&quot;
Identifier &quot;Card0&quot;
EndSection
&lt;/pre&gt;

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 &lt;program &gt;

&lt;program &gt;  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&amp;xboard (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command &quot;OMXPlayer -o hdmi %f &quot;

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 &quot;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

&lt;pre&gt;
# 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
&lt;/pre&gt;

tvservice -c &quot;PAL 4:3&quot;

&lt;pre&gt;
/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:
&lt;/pre&gt;

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&amp;nbsp;nm, peak at 880&amp;nbsp;nm and trails off at 940&amp;nbsp;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:

&lt;pre&gt;
    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
&lt;/pre&gt;


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 &quot;template&quot; 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 &quot;toolchain-core-armhf-build/bin/linux-arm/gen/config&quot; and do make on &quot;toolchain-core-armhf-build&quot; 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 &quot;linklibs-armhf&quot; instead of hd) but it did not solve the automatic building of the missing lib. I must do &quot;linklibs-aeabi-arm-quick&quot;.
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
&quot;cannot find -laeabi &quot; so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.</text>
      <sha1>iksf8m5lkxvlrzcyifl5c2he72ss5av</sha1>
    </revision>
  </page>
  <page>
    <title>Chinese (Mandarin)/Lesson 15</title>
    <ns>0</ns>
    <id>294182</id>
    <revision>
      <id>4657126</id>
      <parentid>4642334</parentid>
      <timestamp>2026-08-11T04:29:10Z</timestamp>
      <contributor>
        <username>HerryCFPL</username>
        <id>3495018</id>
      </contributor>
      <comment>/* Lesson 15: 中国/中國 */</comment>
      <origin>4657126</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1546" sha1="3kx004ghpnfkoj3boe0ruqhfnnfcj0z" xml:space="preserve">{{Chinese (Mandarin)TOC}}
=Lesson 15: 中国/中國=

{| width=&quot;80%&quot;
|-
! Simplified characters
! Pīnyīn
|-
|
中国，全称中华人民共和国，&lt;br /&gt;
是一个由五十六个民族组成的国家，&lt;br /&gt;
位于东亚。&lt;br /&gt;
她&lt;ref&gt;&quot;她&quot; is the feminine third person singular pronoun (&quot;she/her&quot;) and is used to represent a female person. Here, it is used as to represent a nation. This “她” could be used to represent nation, natural elements, the planet etc.&lt;/ref&gt;风景秀丽，历史悠久，文化多元，&lt;br /&gt;
这里的人热情好客，他们优美的语言，&lt;br /&gt;
等着你来探索。&lt;br /&gt;
|
Zhōngguó, quánchēng Zhōnghuá rénmín gònghéguó,&lt;br /&gt;
shì yígè yóu wǔshíliù gè mínzú zǔchéng de guójiā,&lt;br /&gt;
wèiyú dōngyà.&lt;br /&gt;
Tā fēngjǐng xiùlì, lìshǐ yōujiǔ, wénhuà duōyuán,&lt;br /&gt;
zhèlǐ de rén rèqíng hàokè, tāmen yōuměi de yǔyán,&lt;br /&gt;
děngzhe nǐ lái tànsuǒ.&lt;br /&gt;
|}

==English==
China, officially called the People's Republic of China (PRC), is a country in  which  56 different peoples inhabit, located in East Asia. It has beautiful views, a long history, and diverse culture. The people living there welcome you and their wonderful language is waiting for your exploration.

==Vocabulary==
*共和国    /gòng hé guó/ republic
*东亚 /dōng yà/ East Asia
*秀丽 /xiù lì/ beautiful, pretty
*悠久/ yōu jiǔ/ so long 
*多元 /duō yuán/ diverse
*好客/hào kè/ welcome to 
*探索/ tàn suǒ/ n. exploration verb. explore

==Note==


{{BookCat}}</text>
      <sha1>3kx004ghpnfkoj3boe0ruqhfnnfcj0z</sha1>
    </revision>
  </page>
  <page>
    <title>Wikibooks:Edit filter/False positives</title>
    <ns>4</ns>
    <id>396216</id>
    <revision>
      <id>4657144</id>
      <parentid>4655356</parentid>
      <timestamp>2026-08-11T08:15:24Z</timestamp>
      <contributor>
        <username>~2026-44191-83</username>
        <id>3620656</id>
      </contributor>
      <comment>/* {{subst:currentuser}}{{subst:^|DO NOT EDIT THIS LINE}} */ new section</comment>
      <origin>4657144</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="13954" sha1="f3cxgsknpo5mbch7d7nv22yhcotvvvi" xml:space="preserve">__NONEWSECTIONLINK__ __NOINDEX__ {{Wikibooks:Edit filter/False positives/Header}} {{shortcut|WB:EFFP}} {{User:MiszaBot/config
|archive = Wikibooks:Edit filter/False positives/Archive %(counter)d
|algo = old(75d)
|counter = 4
|maxarchivesize = 150K
|minthreadstoarchive = 1
|minthreadsleft = 3
}}

== SHE-LOVES-BRIAN ==

;Username
: [[:b:User:SHE-LOVES-BRIAN|SHE-LOVES-BRIAN]]&lt;span class=&quot;noprint&quot;&gt; {{toolbar|separator=dot
|[[:b:User talk:SHE-LOVES-BRIAN|discuss]]
|[[:b:Special:Emailuser/SHE-LOVES-BRIAN|email]]
|[[:b:Special:Contributions/SHE-LOVES-BRIAN|contribs]]
|[{{fullurl:b:Special:Log|user={{urlencode:SHE-LOVES-BRIAN}}}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;logs&lt;/span&gt;]
|[//tools.wmflabs.org/xtools/pcount/index.php?lang{{=}}en&amp;wiki{{=}}wikibooks&amp;name{{=}}{{urlencode:SHE-LOVES-BRIAN}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;count&lt;/span&gt;]
}}&lt;/span&gt; (&lt;span class=&quot;plainlinks&quot;&gt;[{{fullurl:Special:AbuseLog|wpSearchUser=SHE-LOVES-BRIAN}} filter log]&lt;/span&gt;)
;Page you were editing
: Page not specified
;Description
: 
;Date and time
: 14:35, 5 May 2026 (UTC)
;Comments
&lt;!-- Please leave this area blank for now, but be prepared to answer questions left by reviewing editors. Thanks! --&gt;
: {{EFFP|note}} You are autoconfirmed, which means the filter shouldn't trigger on you anymore, but not all of them to be exact. – [[User:Codename Noreste|&lt;span style=&quot;color:#0024FF&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 15:58, 15 June 2026 (UTC)

== ~2026-32360-90 ==

;Username
: [[:b:User:~2026-32360-90|~2026-32360-90]]&lt;span class=&quot;noprint&quot;&gt; {{toolbar|separator=dot
|[[:b:User talk:~2026-32360-90|discuss]]
|[[:b:Special:Emailuser/~2026-32360-90|email]]
|[[:b:Special:Contributions/~2026-32360-90|contribs]]
|[{{fullurl:b:Special:Log|user={{urlencode:~2026-32360-90}}}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;logs&lt;/span&gt;]
|[//tools.wmflabs.org/xtools/pcount/index.php?lang{{=}}en&amp;wiki{{=}}wikibooks&amp;name{{=}}{{urlencode:~2026-32360-90}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;count&lt;/span&gt;]
}}&lt;/span&gt; (&lt;span class=&quot;plainlinks&quot;&gt;[{{fullurl:Special:AbuseLog|wpSearchUser=%7E2026-32360-90}} filter log]&lt;/span&gt;)
;Page you were editing
: [[Chess Opening Theory/1. e4/1...e5/2. Bc4/2...Bc5/3. Qh5/3...Qe7]] &lt;span class=&quot;plainlinks&quot;&gt;([{{fullurl:Special:AbuseLog|wpSearchTitle=Chess+Opening+Theory%2F1.+e4%2F1...e5%2F2.+Bc4%2F2...Bc5%2F3.+Qh5%2F3...Qe7}} filter log]) ([{{fullurl:Special:AbuseLog|wpSearchTitle=Chess+Opening+Theory%2F1.+e4%2F1...e5%2F2.+Bc4%2F2...Bc5%2F3.+Qh5%2F3...Qe7&amp;wpSearchUser=%7E2026-32360-90}} user filter log])&lt;/span&gt;
;Description
: Trying to add a language ([[:fi:Shakki/rnb1k1nr;ppppqppp;8;2b1p2Q;2B1P3;8;PPPP1PPP;RNB1K1NR w KQkq]]) was being flagged as unconstructive by the edit filter.
;Date and time
: 15:57, 15 June 2026 (UTC)
;Comments
&lt;!-- Please leave this area blank for now, but be prepared to answer questions left by reviewing editors. Thanks! --&gt;

:{{EFFP|rf}} [[User:Codename Noreste|&lt;span style=&quot;color:#0024FF&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 15:57, 15 June 2026 (UTC)

== ~2026-35089-83 ==

;Username
: [[:b:User:~2026-35089-83|~2026-35089-83]]&lt;span class=&quot;noprint&quot;&gt; {{toolbar|separator=dot
|[[:b:User talk:~2026-35089-83|discuss]]
|[[:b:Special:Emailuser/~2026-35089-83|email]]
|[[:b:Special:Contributions/~2026-35089-83|contribs]]
|[{{fullurl:b:Special:Log|user={{urlencode:~2026-35089-83}}}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;logs&lt;/span&gt;]
|[//tools.wmflabs.org/xtools/pcount/index.php?lang{{=}}en&amp;wiki{{=}}wikibooks&amp;name{{=}}{{urlencode:~2026-35089-83}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;count&lt;/span&gt;]
}}&lt;/span&gt; (&lt;span class=&quot;plainlinks&quot;&gt;[{{fullurl:Special:AbuseLog|wpSearchUser=%7E2026-35089-83}} filter log]&lt;/span&gt;)
;Page you were editing
: [[[[Japanese/Kana]]]] &lt;span class=&quot;plainlinks&quot;&gt;([{{fullurl:Special:AbuseLog|wpSearchTitle=%5B%5BJapanese%2FKana%5D%5D}} filter log]) ([{{fullurl:Special:AbuseLog|wpSearchTitle=%5B%5BJapanese%2FKana%5D%5D&amp;wpSearchUser=%7E2026-35089-83}} user filter log])&lt;/span&gt;
;Description
: Tried replacing a dead link with a working version I found when I plugged the link into webarchive, since that's what I presumed I was meant to do when I found a dead link.
;Date and time
: 01:27, 15 June 2026 (UTC)
;Comments
&lt;!-- Please leave this area blank for now, but be prepared to answer questions left by reviewing editors. Thanks! --&gt;
: {{EFFP|done}}  – [[User:Codename Noreste|&lt;span style=&quot;color: blue&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 21:54, 15 July 2026 (UTC)

== SeaDragon1 ==

;Username
: [[:b:User:SeaDragon1|SeaDragon1]]&lt;span class=&quot;noprint&quot;&gt; {{toolbar|separator=dot
|[[:b:User talk:SeaDragon1|discuss]]
|[[:b:Special:Emailuser/SeaDragon1|email]]
|[[:b:Special:Contributions/SeaDragon1|contribs]]
|[{{fullurl:b:Special:Log|user={{urlencode:SeaDragon1}}}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;logs&lt;/span&gt;]
|[//tools.wmflabs.org/xtools/pcount/index.php?lang{{=}}en&amp;wiki{{=}}wikibooks&amp;name{{=}}{{urlencode:SeaDragon1}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;count&lt;/span&gt;]
}}&lt;/span&gt; (&lt;span class=&quot;plainlinks&quot;&gt;[{{fullurl:Special:AbuseLog|wpSearchUser=SeaDragon1}} filter log]&lt;/span&gt;)
;Page you were editing
: [[User:SeaDragon1/UTM highlighting test]] &lt;span class=&quot;plainlinks&quot;&gt;([{{fullurl:Special:AbuseLog|wpSearchTitle=User%3ASeaDragon1%2FUTM+highlighting+test}} filter log]) ([{{fullurl:Special:AbuseLog|wpSearchTitle=User%3ASeaDragon1%2FUTM+highlighting+test&amp;wpSearchUser=SeaDragon1}} user filter log])&lt;/span&gt;
;Description
: Attempted creation of page to test [[User:SeaDragon1/common.js]] (both attempted page creation content and &lt;span style=&quot;font-family: monospace&quot;&gt;common.js&lt;/span&gt; were copied from [[w:Main Page|the English Wikipedia]]).
;Date and time
: 23:26, 3 July 2026 (UTC)
;Comments
&lt;!-- Please leave this area blank for now, but be prepared to answer questions left by reviewing editors. Thanks! --&gt;
:{{EFFP|ad|SeaDragon1}} [[User:Ternera|Ternera]] ([[User talk:Ternera|discuss]] • [[Special:Contributions/Ternera|contribs]]) 16:40, 16 July 2026 (UTC)

==Earthinators==
;Username
: [[:b:User:Earthinators|Earthinators]]&lt;span class=&quot;noprint&quot;&gt; {{toolbar|separator=dot
|[[:b:User talk:Earthinators|discuss]]
|[[:b:Special:Emailuser/Earthinators|email]]
|[[:b:Special:Contributions/Earthinators|contribs]]
|[{{fullurl:b:Special:Log|user={{urlencode:Earthinators}}}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;logs&lt;/span&gt;]
|[//tools.wmflabs.org/xtools/pcount/index.php?lang{{=}}en&amp;wiki{{=}}wikibooks&amp;name{{=}}{{urlencode:Earthinators}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;count&lt;/span&gt;]
}}&lt;/span&gt; (&lt;span class=&quot;plainlinks&quot;&gt;[{{fullurl:Special:AbuseLog|wpSearchUser=Earthinators}} filter log]&lt;/span&gt;)
;Page you were editing
: [[Earthinators]] &lt;span class=&quot;plainlinks&quot;&gt;([{{fullurl:Special:AbuseLog|wpSearchTitle=Earthinators}} filter log]) ([{{fullurl:Special:AbuseLog|wpSearchTitle=Earthinators&amp;wpSearchUser=Earthinators}} user filter log])&lt;/span&gt;
;Description
: I was trying to replace the main page of [[Earthinators]] with a neutral, instructional textbook version ([[Talk:Earthinators|the new text is on the talk page]]). The edit filter blocked me, saying the edit was &quot;potentially unconstructive&quot;. The new version follows Wikibooks guidelines – it’s a textbook, not a promotional page. Please allow the edit or make the change for me.
;Date and time
: 06:56, 11 July 2026 (UTC)
;Comments
&lt;!-- Please leave this area blank for now, but be prepared to answer questions left by reviewing editors. Thanks! --&gt;

:{{EFFP|rf}} [[User:Codename Noreste|Codename Noreste]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 19:48, 16 July 2026 (UTC)

== ~2026-40102-72 ==


;Username
: [[:b:User:~2026-40102-72|~2026-40102-72]]&lt;span class=&quot;noprint&quot;&gt; {{toolbar|separator=dot
|[[:b:User talk:~2026-40102-72|discuss]]
|[[:b:Special:Emailuser/~2026-40102-72|email]]
|[[:b:Special:Contributions/~2026-40102-72|contribs]]
|[{{fullurl:b:Special:Log|user={{urlencode:~2026-40102-72}}}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;logs&lt;/span&gt;]
|[//tools.wmflabs.org/xtools/pcount/index.php?lang{{=}}en&amp;wiki{{=}}wikibooks&amp;name{{=}}{{urlencode:~2026-40102-72}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;count&lt;/span&gt;]
}}&lt;/span&gt; (&lt;span class=&quot;plainlinks&quot;&gt;[{{fullurl:Special:AbuseLog|wpSearchUser=%7E2026-40102-72}} filter log]&lt;/span&gt;)
;Page you were editing
: Page not specified
;Description
: 
;Date and time
: 20:26, 15 July 2026 (UTC)
;Comments
&lt;!-- Please leave this area blank for now, but be prepared to answer questions left by reviewing editors. Thanks! --&gt;
:{{EFFP|nft}} [[User:Ternera|Ternera]] ([[User talk:Ternera|discuss]] • [[Special:Contributions/Ternera|contribs]]) 16:39, 16 July 2026 (UTC)

== ~2026-40102-72 ==


;Username
: [[:b:User:~2026-40102-72|~2026-40102-72]]&lt;span class=&quot;noprint&quot;&gt; {{toolbar|separator=dot
|[[:b:User talk:~2026-40102-72|discuss]]
|[[:b:Special:Emailuser/~2026-40102-72|email]]
|[[:b:Special:Contributions/~2026-40102-72|contribs]]
|[{{fullurl:b:Special:Log|user={{urlencode:~2026-40102-72}}}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;logs&lt;/span&gt;]
|[//tools.wmflabs.org/xtools/pcount/index.php?lang{{=}}en&amp;wiki{{=}}wikibooks&amp;name{{=}}{{urlencode:~2026-40102-72}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;count&lt;/span&gt;]
}}&lt;/span&gt; (&lt;span class=&quot;plainlinks&quot;&gt;[{{fullurl:Special:AbuseLog|wpSearchUser=%7E2026-40102-72}} filter log]&lt;/span&gt;)
;Page you were editing
: Page not specified
;Description
: 
;Date and time
: 20:27, 15 July 2026 (UTC)
;Comments
&lt;!-- Please leave this area blank for now, but be prepared to answer questions left by reviewing editors. Thanks! --&gt;
:{{EFFP|nft}} [[User:Ternera|Ternera]] ([[User talk:Ternera|discuss]] • [[Special:Contributions/Ternera|contribs]]) 16:39, 16 July 2026 (UTC)

== LoveElectronicLiterature ==


;Username
: [[:b:User:LoveElectronicLiterature|LoveElectronicLiterature]]&lt;span class=&quot;noprint&quot;&gt; {{toolbar|separator=dot
|[[:b:User talk:LoveElectronicLiterature|discuss]]
|[[:b:Special:Emailuser/LoveElectronicLiterature|email]]
|[[:b:Special:Contributions/LoveElectronicLiterature|contribs]]
|[{{fullurl:b:Special:Log|user={{urlencode:LoveElectronicLiterature}}}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;logs&lt;/span&gt;]
|[//tools.wmflabs.org/xtools/pcount/index.php?lang{{=}}en&amp;wiki{{=}}wikibooks&amp;name{{=}}{{urlencode:LoveElectronicLiterature}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;count&lt;/span&gt;]
}}&lt;/span&gt; (&lt;span class=&quot;plainlinks&quot;&gt;[{{fullurl:Special:AbuseLog|wpSearchUser=LoveElectronicLiterature}} filter log]&lt;/span&gt;)
;Page you were editing
: [[https://en.wikibooks.org/w/index.php?title=Hereditary_Multiple_Exostoses&amp;veaction=edit&amp;section=7]] &lt;span class=&quot;plainlinks&quot;&gt;([{{fullurl:Special:AbuseLog|wpSearchTitle=https%3A%2F%2Fen.wikibooks.org%2Fw%2Findex.php%3Ftitle%3DHereditary_Multiple_Exostoses%26veaction%3Dedit%26section%3D7}} filter log]) ([{{fullurl:Special:AbuseLog|wpSearchTitle=https%3A%2F%2Fen.wikibooks.org%2Fw%2Findex.php%3Ftitle%3DHereditary_Multiple_Exostoses%26veaction%3Dedit%26section%3D7&amp;wpSearchUser=LoveElectronicLiterature}} user filter log])&lt;/span&gt;
;Description
: I was trying to copy the references and abstracts that I have been maintaining for over 20 years at http COLON SLASH SLASH tinyurl DOT com SLASH MHETalk.  I copied a bunch of references, and then I shortened the description and put the citations in. But I got flagged for copying.  Is there any way to fix this?  thanks!
;Date and time
: 16:23, 16 July 2026 (UTC)
;Comments
&lt;!-- Please leave this area blank for now, but be prepared to answer questions left by reviewing editors. Thanks! --&gt;

== Madan Bibhishan Nagargoje ==


;Username
: [[:b:User:Madan Bibhishan Nagargoje|Madan Bibhishan Nagargoje]]&lt;span class=&quot;noprint&quot;&gt; {{toolbar|separator=dot
|[[:b:User talk:Madan Bibhishan Nagargoje|discuss]]
|[[:b:Special:Emailuser/Madan Bibhishan Nagargoje|email]]
|[[:b:Special:Contributions/Madan Bibhishan Nagargoje|contribs]]
|[{{fullurl:b:Special:Log|user={{urlencode:Madan Bibhishan Nagargoje}}}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;logs&lt;/span&gt;]
|[//tools.wmflabs.org/xtools/pcount/index.php?lang{{=}}en&amp;wiki{{=}}wikibooks&amp;name{{=}}{{urlencode:Madan Bibhishan Nagargoje}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;count&lt;/span&gt;]
}}&lt;/span&gt; (&lt;span class=&quot;plainlinks&quot;&gt;[{{fullurl:Special:AbuseLog|wpSearchUser=Madan+Bibhishan+Nagargoje}} filter log]&lt;/span&gt;)
;Page you were editing
: Page not specified
;Description
: 
;Date and time
: 06:15, 22 July 2026 (UTC)
;Comments
&lt;!-- Please leave this area blank for now, but be prepared to answer questions left by reviewing editors. Thanks! --&gt;

== ~2026-44191-83 ==


;Username
: [[:b:User:~2026-44191-83|~2026-44191-83]]&lt;span class=&quot;noprint&quot;&gt; {{toolbar|separator=dot
|[[:b:User talk:~2026-44191-83|discuss]]
|[[:b:Special:Emailuser/~2026-44191-83|email]]
|[[:b:Special:Contributions/~2026-44191-83|contribs]]
|[{{fullurl:b:Special:Log|user={{urlencode:~2026-44191-83}}}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;logs&lt;/span&gt;]
|[//tools.wmflabs.org/xtools/pcount/index.php?lang{{=}}en&amp;wiki{{=}}wikibooks&amp;name{{=}}{{urlencode:~2026-44191-83}} &lt;span style{{=}}&quot;color:#002bb8&quot;&gt;count&lt;/span&gt;]
}}&lt;/span&gt; (&lt;span class=&quot;plainlinks&quot;&gt;[{{fullurl:Special:AbuseLog|wpSearchUser=%7E2026-44191-83}} filter log]&lt;/span&gt;)
;Page you were editing
: [[An_Introduction_to_Dragon]] &lt;span class=&quot;plainlinks&quot;&gt;([{{fullurl:Special:AbuseLog|wpSearchTitle=An_Introduction_to_Dragon}} filter log]) ([{{fullurl:Special:AbuseLog|wpSearchTitle=An_Introduction_to_Dragon&amp;wpSearchUser=%7E2026-44191-83}} user filter log])&lt;/span&gt;
;Description
: Adding/expanding book content (introduction, table of contents, and lesson pages) for the Dragon programming language wikibook, based on the project's own source code and documentation. No spam or promotional intent.
;Date and time
: 08:15, 11 August 2026 (UTC)
;Comments
&lt;!-- Please leave this area blank for now, but be prepared to answer questions left by reviewing editors. Thanks! --&gt;</text>
      <sha1>f3cxgsknpo5mbch7d7nv22yhcotvvvi</sha1>
    </revision>
  </page>
  <page>
    <title>An Introduction to Dragon/Lessons/Introduction</title>
    <ns>0</ns>
    <id>406842</id>
    <revision>
      <id>4657136</id>
      <parentid>4382600</parentid>
      <timestamp>2026-08-11T07:52:44Z</timestamp>
      <contributor>
        <username>~2026-44191-83</username>
        <id>3620656</id>
      </contributor>
      <comment>Updated book content as per new version of Dragon</comment>
      <origin>4657136</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1413" sha1="adoqypobb8f1icd83ldqmsn1aqjs20y" xml:space="preserve">== Introduction ==

'''Dragon''' is an innovative, practical, general-purpose programming language designed to be simple, small, flexible, and fast. It has an expressive, readable syntax that is easy to pick up, and it supports multiple programming paradigms: imperative, object-oriented, functional, and declarative.

Dragon programs can be run directly as scripts, explored interactively in a REPL, bundled into a single self-contained executable for distribution, or compiled into a shared library for embedding inside other applications.

This book will walk through the language from the ground up: variables and operators, control structures, functions, collections, classes and object-oriented programming, error handling, the standard library, concurrency, and finally how to compile and distribute finished Dragon programs.

=== Who this book is for ===

This book assumes basic familiarity with programming concepts (variables, loops, functions) but does not assume prior knowledge of Dragon itself. Readers coming from JavaScript, Python, or Lua will recognize many of Dragon's constructs.

=== How to use this book ===

Each chapter builds on the previous one. Code samples are written to be typed into a file with a &lt;code&gt;.dgn&lt;/code&gt; extension and run with:

&lt;syntaxhighlight lang=&quot;bash&quot;&gt;
dragon myfile.dgn
&lt;/syntaxhighlight&gt;

or explored directly in the interactive REPL, covered in the next lesson.</text>
      <sha1>adoqypobb8f1icd83ldqmsn1aqjs20y</sha1>
    </revision>
  </page>
  <page>
    <title>An Introduction to Dragon/Lessons/Features</title>
    <ns>0</ns>
    <id>406843</id>
    <revision>
      <id>4657138</id>
      <parentid>4382590</parentid>
      <timestamp>2026-08-11T08:01:42Z</timestamp>
      <contributor>
        <username>~2026-44191-83</username>
        <id>3620656</id>
      </contributor>
      <origin>4657138</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2667" sha1="1v2c63b3mpgwmx3kuvoyeq8t3faomiw" xml:space="preserve">== Features ==

Dragon aims to give a scripting-language &quot;feel&quot; — quick to write, nothing to configure — while still offering the constructs needed for larger programs.

=== Language features ===

* '''Simple, readable syntax''' — spend less time fighting the language, more time solving problems.
* '''Dynamic and weak typing''' — variables need no type declaration and are checked at run time.
* '''First-class functions and closures''', including arrow-function '''lambdas'''.
* '''Classes''' with constructors (&lt;code&gt;init&lt;/code&gt;), inheritance (&lt;code&gt;extends&lt;/code&gt;), the &lt;code&gt;this&lt;/code&gt; and &lt;code&gt;super&lt;/code&gt; keywords, and method overriding.
* '''Familiar control flow''': &lt;code&gt;if&lt;/code&gt; / &lt;code&gt;elif&lt;/code&gt; / &lt;code&gt;else&lt;/code&gt;, &lt;code&gt;while&lt;/code&gt;, &lt;code&gt;do&lt;/code&gt; / &lt;code&gt;while&lt;/code&gt;, &lt;code&gt;for ... in&lt;/code&gt;, &lt;code&gt;switch&lt;/code&gt; / &lt;code&gt;case&lt;/code&gt;, and a ternary operator.
* '''Structured error handling''' with &lt;code&gt;try&lt;/code&gt; / &lt;code&gt;catch&lt;/code&gt; / &lt;code&gt;finally&lt;/code&gt; and &lt;code&gt;raise&lt;/code&gt;.
* '''String interpolation''' using backtick strings with &lt;code&gt;${expr}&lt;/code&gt; placeholders, plus a &lt;code&gt;format()&lt;/code&gt; function for fine-grained output control (padding, decimal precision, and so on).
* '''Built-in collections''': dynamically sized lists and ordered maps, each with a rich set of methods (&lt;code&gt;push&lt;/code&gt;, &lt;code&gt;map&lt;/code&gt;, &lt;code&gt;filter&lt;/code&gt;, &lt;code&gt;reduce&lt;/code&gt;, &lt;code&gt;sort&lt;/code&gt;, &lt;code&gt;set&lt;/code&gt;, and more).
* '''Constants''' declared with &lt;code&gt;const&lt;/code&gt; that cannot be reassigned after they are set.
* '''Concurrency''' via &lt;code&gt;async&lt;/code&gt; / &lt;code&gt;await&lt;/code&gt; and a &lt;code&gt;thread&lt;/code&gt; module for spawning worker threads.
* '''Modules''', imported with a simple &lt;code&gt;import&lt;/code&gt; statement, covering everything from math to networking to cryptography.

=== Tooling and distribution features ===

* '''Portable''' across Windows, Linux, and macOS.
* An '''interactive REPL''' (&lt;code&gt;dragon --repl&lt;/code&gt;) for exploring the language line by line.
* '''Native compilation (experimental)''' — transpile Dragon source to C and build it with the system C compiler.
* '''Self-contained executables''' — bundle a script and its dependencies into a single encrypted, distributable binary with &lt;code&gt;dragon -c&lt;/code&gt;.
* '''Shared library builds''' — compile Dragon scripts into a &lt;code&gt;.dll&lt;/code&gt; / &lt;code&gt;.so&lt;/code&gt; / &lt;code&gt;.dylib&lt;/code&gt; for embedding in other applications.
* The '''TurboDragon IDE''' — a built-in terminal UI editor/runner, launched with &lt;code&gt;dragon --ide&lt;/code&gt;.
* '''Package-based projects''' — run a project directly from a &lt;code&gt;package.json&lt;/code&gt; manifest with &lt;code&gt;dragon run&lt;/code&gt;.</text>
      <sha1>1v2c63b3mpgwmx3kuvoyeq8t3faomiw</sha1>
    </revision>
  </page>
  <page>
    <title>An Introduction to Dragon/Lessons/HelloWorld</title>
    <ns>0</ns>
    <id>406844</id>
    <revision>
      <id>4657140</id>
      <parentid>4382596</parentid>
      <timestamp>2026-08-11T08:05:53Z</timestamp>
      <contributor>
        <username>~2026-44191-83</username>
        <id>3620656</id>
      </contributor>
      <comment>Updated book content as per new version of Dragon</comment>
      <origin>4657140</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1537" sha1="qw8cnpdd1bowep67nm7i4w696qj6ms0" xml:space="preserve">== Hello World ==

Create a file named &lt;code&gt;hello.dgn&lt;/code&gt;:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
func main() {
    showln(&quot;Hello, World!&quot;)
}

main()
&lt;/syntaxhighlight&gt;

&lt;code&gt;showln&lt;/code&gt; prints its arguments followed by a newline. Its counterpart, &lt;code&gt;show&lt;/code&gt;, prints without a trailing newline.

=== Run the program ===

&lt;syntaxhighlight lang=&quot;bash&quot;&gt;
dragon hello.dgn
&lt;/syntaxhighlight&gt;

Any extra arguments after the filename are passed through to the script and become available inside Dragon code as &lt;code&gt;argv&lt;/code&gt;.

=== The REPL ===

Dragon also has a persistent interactive session:

&lt;syntaxhighlight lang=&quot;bash&quot;&gt;
dragon --repl
&lt;/syntaxhighlight&gt;

Variables and functions defined on one line remain available on the next, which makes the REPL convenient for quickly trying things out. Type &lt;code&gt;exit&lt;/code&gt; to leave the REPL.

=== Multi-Line literals ===

Backtick strings can span multiple lines and support &lt;code&gt;${expr}&lt;/code&gt; interpolation:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
name = &quot;Dragon&quot;
version = 1.0

showln(`Welcome to ${name} v${version}!`)
&lt;/syntaxhighlight&gt;

=== Getting Input ===

The &lt;code&gt;readln()&lt;/code&gt; function reads a line of text typed by the user. See [[/Lessons/Getting_Input|Getting Input]] for full details.

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
showln(&quot;What is your name?&quot;)
name = readln()
showln(`Hello, ${name}!`)
&lt;/syntaxhighlight&gt;

=== Writing Comments ===

Dragon uses C-style comments:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
// A single-line comment

/*
   A multi-line
   comment block
*/
&lt;/syntaxhighlight&gt;</text>
      <sha1>qw8cnpdd1bowep67nm7i4w696qj6ms0</sha1>
    </revision>
  </page>
  <page>
    <title>An Introduction to Dragon/Lessons/Variables</title>
    <ns>0</ns>
    <id>406845</id>
    <revision>
      <id>4657141</id>
      <parentid>4382604</parentid>
      <timestamp>2026-08-11T08:07:43Z</timestamp>
      <contributor>
        <username>~2026-44191-83</username>
        <id>3620656</id>
      </contributor>
      <origin>4657141</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2249" sha1="h96dxfqwn808ljsgkivdsfzwg3m61x4" xml:space="preserve">== Variables ==

Variables in Dragon require no type declaration or keyword — assignment creates them:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
name = &quot;Dragon&quot;
version = 1.0
age = 5
is_awesome = True
&lt;/syntaxhighlight&gt;

=== Dynamic Typing ===

A variable's type is determined by the value currently assigned to it, and can change over the variable's lifetime:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
x = 10        // x is a number
x = &quot;ten&quot;     // now x is a string
x = [1, 2, 3] // now x is a list
&lt;/syntaxhighlight&gt;

Use &lt;code&gt;typeof()&lt;/code&gt; to inspect a value's current type at run time:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
showln(&quot;typeof age:&quot;, typeof(age))
&lt;/syntaxhighlight&gt;

=== Weakly Typed ===

Dragon is weakly typed: operators will implicitly convert between compatible types rather than raising an error, so mixing numbers and strings in certain expressions is generally permitted rather than rejected outright.

=== Deep Copy ===

Collections (lists and maps) are reference types by default. When a genuinely independent copy is required — so that modifying the copy does not affect the original — Dragon provides deep-copy semantics for collections rather than only copying the reference. Always check whether you need a reference or a copy before assigning a list or map to a new variable.

=== Constants ===

Values declared with &lt;code&gt;const&lt;/code&gt; cannot be reassigned after they are set:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
const GREETING = &quot;Hello&quot;
showln(GREETING + &quot;, World!&quot;)
&lt;/syntaxhighlight&gt;

=== typeof() and Type Conversions ===

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
showln(&quot;str(age):&quot;, str(age))
showln(&quot;int(\&quot;42\&quot;):&quot;, int(&quot;42&quot;))
&lt;/syntaxhighlight&gt;

&lt;code&gt;str()&lt;/code&gt;, &lt;code&gt;int()&lt;/code&gt;, and related conversion functions coerce a value to the requested type.

=== String Interpolation ===

Backtick strings support &lt;code&gt;${expr}&lt;/code&gt; placeholders, evaluated and inserted at run time:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
a = 10
b = 3
showln(`${a} + ${b} = ${a + b}`)
&lt;/syntaxhighlight&gt;

=== Formatting Output ===

&lt;code&gt;format()&lt;/code&gt; gives fine-grained control over how a value is rendered:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
pi = 3.14159
showln(format(&quot;Pi rounded to 2 places: {:.2f}&quot;, pi))
showln(format(&quot;Padded number: [{:&gt;6}]&quot;, 42))
&lt;/syntaxhighlight&gt;</text>
      <sha1>h96dxfqwn808ljsgkivdsfzwg3m61x4</sha1>
    </revision>
  </page>
  <page>
    <title>An Introduction to Dragon/Lessons/History</title>
    <ns>0</ns>
    <id>406848</id>
    <revision>
      <id>4657137</id>
      <parentid>4382598</parentid>
      <timestamp>2026-08-11T07:57:40Z</timestamp>
      <contributor>
        <username>~2026-44191-83</username>
        <id>3620656</id>
      </contributor>
      <comment>Updated book content as per new version of Dragon</comment>
      <origin>4657137</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1995" sha1="ocogvdv9itb4k6n0embtfqyo13vfohf" xml:space="preserve">== History ==

Dragon was created by '''Aavesh Jilani''', who authored the reference implementation and continues to maintain the project. Dragon began as a project to build a small, fast, embeddable scripting language with a friendlier surface syntax than many existing dynamic languages. The reference implementation is written entirely in Rust, which gives the interpreter memory safety without a garbage-collected host runtime, and makes the toolchain (the &lt;code&gt;dragon&lt;/code&gt; CLI, its bytecode VM, and its optional C transpiler) easy to build and distribute as a single native binary.

Over time the language grew from a simple tree-walking interpreter into a full pipeline:

# A hand-written '''lexer''' and '''recursive-descent parser''' producing an AST.
# A '''bytecode compiler''' that lowers the AST into a compact instruction set.
# A '''stack-based virtual machine''' that executes the compiled bytecode.
# An experimental '''AST-to-C transpiler''' (&lt;code&gt;codegen_c&lt;/code&gt;) that allows performance-sensitive or distribution-sensitive programs to be compiled to a native binary instead of interpreted.

Alongside the language core, the project grew a standard library of built-in modules (&lt;code&gt;math&lt;/code&gt;, &lt;code&gt;json&lt;/code&gt;, &lt;code&gt;file&lt;/code&gt;, &lt;code&gt;path&lt;/code&gt;, &lt;code&gt;os&lt;/code&gt;, &lt;code&gt;time&lt;/code&gt;, &lt;code&gt;net&lt;/code&gt;, &lt;code&gt;crypto&lt;/code&gt;, &lt;code&gt;zip&lt;/code&gt;, &lt;code&gt;xml&lt;/code&gt;, &lt;code&gt;uuid&lt;/code&gt;, &lt;code&gt;pdf&lt;/code&gt;, &lt;code&gt;font&lt;/code&gt;, &lt;code&gt;ffi&lt;/code&gt;, &lt;code&gt;struct&lt;/code&gt;, &lt;code&gt;mem&lt;/code&gt;, and &lt;code&gt;thread&lt;/code&gt;), a package-based project runner (&lt;code&gt;dragon run&lt;/code&gt;, driven by a &lt;code&gt;package.json&lt;/code&gt; manifest), and a terminal user-interface editor nicknamed the '''TurboDragon IDE''', launched with &lt;code&gt;dragon --ide&lt;/code&gt;.

The project is open source and distributed under the '''MIT License''', copyright Aavesh Jilani. The canonical source repository and issue tracker are the primary place where the language's ongoing history is tracked release-by-release.

{{stub}}</text>
      <sha1>ocogvdv9itb4k6n0embtfqyo13vfohf</sha1>
    </revision>
  </page>
  <page>
    <title>An Introduction to Dragon</title>
    <ns>0</ns>
    <id>406849</id>
    <revision>
      <id>4657135</id>
      <parentid>4452266</parentid>
      <timestamp>2026-08-11T07:44:10Z</timestamp>
      <contributor>
        <username>~2026-44191-83</username>
        <id>3620656</id>
      </contributor>
      <origin>4657135</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="7513" sha1="ppfmernt593uan32944acd815xjbu6x" xml:space="preserve">&lt;div style=&quot;text-align:center; width:100%;&quot;&gt;&lt;big&gt;&lt;big&gt;'''An introduction to'''&lt;/big&gt;&lt;/big&gt;
[[File:DragonLogo.jpg|200px|center|The Dragon programming language logo]]
[http://dragon-lang.org &lt;big&gt;&lt;big&gt;'''The Dragon &lt;span lang=&quot;tr&quot; dir=&quot;ltr&quot;&gt;Programming&lt;/span&gt; Language'''&lt;/big&gt;&lt;/big&gt;]
&lt;/div&gt;

'''Dragon''' is an innovative and practical general-purpose, multi-paradigm programming language. It supports multiple programming paradigms — imperative, object-oriented, functional, procedural, and declarative — with an expressive, readable syntax that is easy to pick up. Dragon is dynamically and weakly typed, is portable across Windows, Linux, and macOS, and can be used to build console applications.

Under the hood, Dragon source is tokenized by a lexer, parsed into an abstract syntax tree, compiled to bytecode, and executed by a register/stack-based virtual machine written in Rust. For advanced use cases, Dragon scripts can also be transpiled to C and compiled natively with the system's C compiler (gcc, clang, or MSVC), bundled into a single self-contained encrypted executable, or built as a shared library (&lt;code&gt;.dll&lt;/code&gt; / &lt;code&gt;.so&lt;/code&gt; / &lt;code&gt;.dylib&lt;/code&gt;) for embedding in other applications.

Dragon ships with a batteries-included standard library covering math, JSON, the filesystem, the OS environment, dates and timers, HTTP networking, cryptography, ZIP archives, XML, UUIDs, PDF/font rendering, and native FFI interop — all available through a simple &lt;code&gt;import&lt;/code&gt; statement. It also includes built-in support for &lt;code&gt;async&lt;/code&gt;/&lt;code&gt;await&lt;/code&gt; and a &lt;code&gt;thread&lt;/code&gt; module for concurrent programming, an interactive REPL, a package-based project runner driven by &lt;code&gt;package.json&lt;/code&gt;, and a terminal-based editor called the TurboDragon IDE.

== Table of Contents ==
{{Book search}}
{{Print version}}

=== Getting Started ===
*[[/Lessons/Introduction|Introduction]]
*[[/Lessons/History|History]]
*[[/Lessons/Features|Features]]
*[[/Lessons/Installation|Installation and Building from Source]]
*[[/Lessons/HelloWorld#Hello_World|Hello World]]
*[[/Lessons/HelloWorld#Run_the_program|Run the program]]
*[[/Lessons/HelloWorld#The_REPL|The Interactive REPL]]
*[[/Lessons/HelloWorld#Multi-Line_literals|Multi-Line literals]]
*[[/Lessons/HelloWorld#Getting_Input|Getting Input]]
*[[/Lessons/HelloWorld#Writing_Comments|Writing Comments]]

=== Variables ===
*[[/Lessons/Variables|Variables]]
*[[/Lessons/Variables#Dynamic_Typing|Dynamic Typing]]
*[[/Lessons/Variables#Deep_Copy|Deep Copy]]
*[[/Lessons/Variables#Weakly_Typed|Weakly Typed]]
*[[/Lessons/Variables#Constants|Constants]]
*[[/Lessons/Variables#typeof_and_Conversions|typeof() and Type Conversions]]
*[[/Lessons/Variables#String_Interpolation|String Interpolation]]
*[[/Lessons/Variables#Formatting_Output|Formatting Output with format()]]

=== Operators ===
*[[/Lessons/Operators|Operators]]
*[[/Lessons/Operators#Arithmetic_Operators|Arithmetic Operators]]
*[[/Lessons/Operators#Relational_Operators|Relational Operators]]
*[[/Lessons/Operators#Logical_Operators|Logical Operators]]
*[[/Lessons/Operators#Bitwise_Operators|Bitwise Operators]]
*[[/Lessons/Operators#Assignment_Operators|Assignment Operators]]
*[[/Lessons/Operators#Ternary_Operator|Ternary Operator]]
*[[/Lessons/Operators#Misc_Operators|Misc Operators]]
*[[/Lessons/Operators#Operator_Precedence|Operator Precedence]]

=== Control Structures ===
*[[/Lessons/Control_Structures|Control Structures]]
*[[/Lessons/Control_Structures#Branching|Branching: if / elif / else]]
*[[/Lessons/Control_Structures#Looping|Looping: while]]
*[[/Lessons/Control_Structures#Do_While_Loop|Do While Loop]]
*[[/Lessons/Control_Structures#For_In_Loop|For-In Loop over Lists and Maps]]
*[[/Lessons/Control_Structures#Break_and_Continue|Break and Continue]]
*[[/Lessons/Control_Structures#Switch_Case|Switch / Case]]

=== Getting Input ===
*[[/Lessons/Getting_Input|Getting Input]]
*[[/Lessons/Getting_Input#readln_function|readln function]]
*[[/Lessons/Getting_Input#Command_Line_Arguments|Command Line Arguments (argv)]]

=== Functions ===
*[[/Lessons/Functions|Functions]]
*[[/Lessons/Functions#Define_Functions|Define Functions]]
*[[/Lessons/Functions#Call_Functions|Call Functions]]
*[[/Lessons/Functions#Declare_parameters|Declare Parameters]]
*[[/Lessons/Functions#Default_Parameters|Default Parameter Values]]
*[[/Lessons/Functions#Rest_Parameters|Rest Parameters]]
*[[/Lessons/Functions#Send_Parameters|Send Parameters]]
*[[/Lessons/Functions#Variables_Scope|Variables Scope]]
*[[/Lessons/Functions#Return_Value|Return Value]]
*[[/Lessons/Functions#Lambdas|Lambdas (Arrow Functions)]]

=== Collections ===
*[[/Lessons/Collections|Collections]]
*[[/Lessons/Collections#Lists|Lists]]
*[[/Lessons/Collections#List_Methods|List Methods: push, map, filter, reduce, sort]]
*[[/Lessons/Collections#Maps|Maps]]
*[[/Lessons/Collections#Map_Methods|Map Methods: set, iteration]]
*[[/Lessons/Collections#Strings_as_Collections|String Methods: trim, upper, lower, split, contains, replace]]

=== Classes and Object-Oriented Programming ===
*[[/Lessons/Classes|Classes]]
*[[/Lessons/Classes#Defining_a_Class|Defining a Class]]
*[[/Lessons/Classes#Constructors|Constructors with init()]]
*[[/Lessons/Classes#This|The this Keyword]]
*[[/Lessons/Classes#Creating_Instances|Creating Instances with new]]
*[[/Lessons/Classes#Inheritance|Inheritance with extends]]
*[[/Lessons/Classes#Super|Calling Parent Methods with super]]
*[[/Lessons/Classes#Method_Overriding|Method Overriding]]

=== Error Handling ===
*[[/Lessons/Error_Handling|Error Handling]]
*[[/Lessons/Error_Handling#Try_Catch_Finally|try / catch / finally]]
*[[/Lessons/Error_Handling#Raising_Errors|Raising Errors with raise]]
*[[/Lessons/Error_Handling#Scope_of_Catches|Scope of try/catch]]

=== Modules and the Standard Library ===
*[[/Lessons/Modules|Modules and import]]
*[[/Lessons/Modules#math|math — Numeric and Math Utilities]]
*[[/Lessons/Modules#json|json — Encoding and Decoding JSON]]
*[[/Lessons/Modules#file_path|file / path — Filesystem Access]]
*[[/Lessons/Modules#os|os — Environment and System Info]]
*[[/Lessons/Modules#time|time — Dates, Timers, and Sleeping]]
*[[/Lessons/Modules#net|net — HTTP Client and Server]]
*[[/Lessons/Modules#crypto|crypto — Hashing, HMAC, PBKDF2, AES-GCM]]
*[[/Lessons/Modules#zip_xml_uuid|zip, xml, and uuid]]
*[[/Lessons/Modules#pdf_font|pdf and font — Document and Text Rendering]]
*[[/Lessons/Modules#ffi|ffi / struct / mem — Native Interop]]

=== Concurrency ===
*[[/Lessons/Concurrency|Concurrency]]
*[[/Lessons/Concurrency#Async_Await|async / await]]
*[[/Lessons/Concurrency#Threading|The thread Module]]

=== Compiling and Distribution ===
*[[/Lessons/Compiling|Compiling and Distribution]]
*[[/Lessons/Compiling#Bundling_Executables|Bundling Self-Contained Executables]]
*[[/Lessons/Compiling#Shared_Libraries|Building Shared Libraries]]
*[[/Lessons/Compiling#Native_Compilation|Native Compilation via C Transpiling]]
*[[/Lessons/Compiling#Package_Projects|Running Package Projects with package.json]]

=== Tooling ===
*[[/Lessons/Tooling|Tooling]]
*[[/Lessons/Tooling#TurboDragon_IDE|The TurboDragon Terminal IDE]]
*[[/Lessons/Tooling#REPL|Using the REPL Effectively]]

=== Appendices ===
*[[/Appendices/Standard_Library_Reference|Standard Library Reference]]
*[[/Appendices/Command_Line_Reference|Command Line Reference]]
*[[/Appendices/Glossary|Glossary]]

{{Shelves|Computer programming languages}}
{{status | 25% }}
__NOTOC__</text>
      <sha1>ppfmernt593uan32944acd815xjbu6x</sha1>
    </revision>
  </page>
  <page>
    <title>Wikibooks:GUS2Wiki</title>
    <ns>4</ns>
    <id>447875</id>
    <revision>
      <id>4657134</id>
      <parentid>4656050</parentid>
      <timestamp>2026-08-11T07:29:05Z</timestamp>
      <contributor>
        <username>Alexis Jazz</username>
        <id>470964</id>
      </contributor>
      <comment>Updating gadget usage statistics from [[Special:GadgetUsage]] ([[phab:T121049]])</comment>
      <origin>4657134</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2048" sha1="iffvqffzn878p230a7pzfs5df9orcbn" xml:space="preserve">{{#ifexist:Project:GUS2Wiki/top|{{/top}}|This page provides a historical record of [[Special:GadgetUsage]] through its page history. To get the data in CSV format, see wikitext. To customize this message or add categories, create [[/top]].}}
The following data is cached, and was last updated 2026-08-10T06:28:58Z. A maximum of {{PLURAL:5000|one result is|5000 results are}} available in the cache.
{| class=&quot;sortable wikitable&quot;
! Gadget !! data-sort-type=&quot;number&quot; | Number of users !! data-sort-type=&quot;number&quot; | Active users
|-
|BookCat || 106 || 2
|-
|CleanDeleteReasons || 54 || 1
|-
|CommentsInLocalTime || 667 || 4
|-
|DeluxeBar || 209 || 4
|-
|GetCollection || 552 || 0
|-
|HotCat || 7 || 1
|-
|Massblock || 1 || 1
|-
|OneClickWelcomer || 27 || 0
|-
|SpecialSearch || 664 || 1
|-
|Subpages || 1 || 1
|-
|UTCLiveClock || 369 || 5
|-
|background-awesomeness || 787 || 5
|-
|bottomtabs || 431 || 1
|-
|commons-file || data-sort-value=&quot;Infinity&quot; | Default || data-sort-value=&quot;Infinity&quot; | Default
|-
|contribsrange || 331 || 6
|-
|markAdmins || 145 || 10
|-
|markblocked || 59 || 3
|-
|modrollback || 83 || 2
|-
|navpop || 843 || 8
|-
|purge || 620 || 7
|-
|rightsfilter || 373 || 3
|-
|searchbox || 211 || 4
|-
|sidebartranslate || 504 || 2
|-
|sixtabs || 312 || 0
|-
|subject-pages || 612 || 2
|-
|subpages || 30 || 5
|-
|wiked || 669 || 2
|-
|wikidialog || data-sort-value=&quot;Infinity&quot; | Default || data-sort-value=&quot;Infinity&quot; | Default
|}
* [[Special:GadgetUsage]]
* [[m:Meta:GUS2Wiki/Script|GUS2Wiki]]
&lt;!-- data in CSV format:
BookCat,106,2
CleanDeleteReasons,54,1
CommentsInLocalTime,667,4
DeluxeBar,209,4
GetCollection,552,0
HotCat,7,1
Massblock,1,1
OneClickWelcomer,27,0
SpecialSearch,664,1
Subpages,1,1
UTCLiveClock,369,5
background-awesomeness,787,5
bottomtabs,431,1
commons-file,default,default
contribsrange,331,6
markAdmins,145,10
markblocked,59,3
modrollback,83,2
navpop,843,8
purge,620,7
rightsfilter,373,3
searchbox,211,4
sidebartranslate,504,2
sixtabs,312,0
subject-pages,612,2
subpages,30,5
wiked,669,2
wikidialog,default,default
--&gt;</text>
      <sha1>iffvqffzn878p230a7pzfs5df9orcbn</sha1>
    </revision>
  </page>
  <page>
    <title>User talk:Xeverything11/updates</title>
    <ns>3</ns>
    <id>452115</id>
    <revision>
      <id>4657105</id>
      <parentid>4656881</parentid>
      <timestamp>2026-08-10T20:46:14Z</timestamp>
      <contributor>
        <username>MediaWiki message delivery</username>
        <id>1188004</id>
      </contributor>
      <comment>/* Tech News: 2026-33 */ new section</comment>
      <origin>4657105</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1128845" sha1="3qq34o89d79y284q7oc13v6067xax06" xml:space="preserve">&lt;noinclude&gt;
{{User:Xeverything11/tabs}}

{{User:Xeverything11/header|Welcome to|Xeverything11's|updates talk page!|archives=
* [[User talk:Xeverything11/archives/2022|2022]]
* [[User talk:Xeverything11/archives/2023|2023]]
}}
&lt;/noinclude&gt;
__NOTOC__
{{User:MiszaBot/config
|archive = User talk:Xeverything11/archives/%(year)d
|algo = old(60d)
|counter = 1
|minthreadsleft = 1
|minthreadstoarchive = 1
}}
== Tech News: 2023-03 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W03&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/03|Translations]] are available.

'''Problems'''
* [[File:Octicons-tools.svg|15px|link=|alt=|Advanced item]] The URLs in &quot;{{int:last}}&quot; links on page history now contain &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;diff=prev&amp;oldid=[revision ID]&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; in place of &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;diff=[revision ID]&amp;oldid=[revision ID]&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;. This is to fix a problem with links pointing to incorrect diffs when history was filtered by a tag. Some user scripts may break as a result of this change. [https://phabricator.wikimedia.org/T243569]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.40/wmf.19|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-01-17|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-01-18|en}}. It will be on all wikis from {{#time:j xg|2023-01-19|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).
* Some [[mw:Special:MyLanguage/Talk pages project/Usability|changes to the appearance of talk pages]] have only been available on &lt;code&gt;{{ns:1}}:&lt;/code&gt; and &lt;code&gt;{{ns:3}}:&lt;/code&gt; namespaces.  These will be extended to other talk namespaces, such as &lt;code&gt;{{ns:5}}:&lt;/code&gt;.  They will continue to be unavailable in non-talk namespaces, including &lt;code&gt;{{ns:4}}:&lt;/code&gt; pages (e.g., at the Village Pump).  You can [[Special:Preferences#mw-prefsection-editing-discussion|change your preferences]] ([[Special:Preferences#mw-prefsection-betafeatures|beta feature]]). [https://phabricator.wikimedia.org/T325417]
*On Wikisources, when an image is zoomed or panned in the Page: namespace, the same zoom and pan settings will be remembered for all Page: namespace pages that are linked to a particular Index: namespace page. [https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/868841]
* The Vector 2022 skin will become the default for the English Wikipedia desktop users. The change will take place on January 18 at 15:00 UTC. [[:en:w:Wikipedia:Vector 2022|Learn more]].

'''Future changes'''
* The 2023 edition of the [[m:Special:MyLanguage/Community Wishlist Survey 2023|Community Wishlist Survey]], which invites contributors to make technical proposals and vote for tools and improvements, starts next week on 23 January 2023 at 18:00 UTC. You can start drafting your proposals in [[m:Community Wishlist Survey/Sandbox|the CWS sandbox]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/03|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W03&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:11, 17 January 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24381020 --&gt;

== Tech News: 2023-04 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W04&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/04|Translations]] are available.

'''Problems'''
* Last week, for ~15 minutes, all wikis were unreachable for logged-in users and non-cached pages. This was caused by a timing issue. [https://wikitech.wikimedia.org/wiki/Incidents/2023-01-17_MediaWiki]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.40/wmf.20|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-01-24|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-01-25|en}}. It will be on all wikis from {{#time:j xg|2023-01-26|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).
* If you have the Beta Feature for [[mw:Special:MyLanguage/Talk pages project|DiscussionTools]] enabled, the appearance of talk pages will add more information about discussion activity. [https://www.mediawiki.org/wiki/Special:MyLanguage/Talk_pages_project/Usability#Status][https://phabricator.wikimedia.org/T317907]
* The 2023 edition of the [[m:Special:MyLanguage/Community Wishlist Survey 2023|Community Wishlist Survey]] (CWS), which invites contributors to make technical proposals and vote for tools and improvements, starts on Monday 23 January 2023 at [https://zonestamp.toolforge.org/1674496814 18:00 UTC]. 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/04|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W04&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:46, 23 January 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24418874 --&gt;

== Tech News: 2023-05 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W05&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/05|Translations]] are available.

'''Problems'''
* Last week, for ~15 minutes, some users were unable to log in or edit pages. This was caused by a problem with session storage. [https://wikitech.wikimedia.org/wiki/Incidents/2023-01-24_sessionstore_quorum_issues]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.40/wmf.21|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-01-31|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-02-01|en}}. It will be on all wikis from {{#time:j xg|2023-02-02|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).

'''Future changes'''
* [[File:Octicons-tools.svg|15px|link=|alt=|Advanced item]] Wikis that use localized numbering schemes for references need to add new CSS. This will help to show citation numbers the same way in all reading and editing modes. If your wiki would prefer to do it yourselves, please see the [[mw:Special:MyLanguage/Parsoid/Parser Unification/Cite CSS|details and example CSS to copy from]], and also add your wiki to the list. Otherwise, the developers will directly help out starting the week of February 5.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/05|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W05&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:06, 31 January 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24455949 --&gt;

== Wikipedia translation of the week: 2023-06 {{User:Xeverything11/tags/updates}} ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Sweden Finns' Day]] '''&lt;br /&gt; &lt;small&gt;''([[:fi:Ruotsinsuomalaisten päivä]]) ([[:sv:Sverigefinnarnas dag]])''&lt;/small&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Sverigefinskaflaggan.svg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Sweden Finns' Day''' (Finnish: Ruotsinsuomalaisten päivä, Swedish: Sverigefinnarnas dag) is an anniversary celebrated in Sweden on 24 February. The anniversary of the calendar was approved by the Swedish Academy in 2010 and was celebrated for the first time in 2011. February 24 was chosen as the birthday of Carl Axel Gottlund, a collector of folk poetry and a defender of the status of the Finnish language. The purpose of the day is to celebrate the Sweden Finns and to recognize their history, language and culture as a prominent part of Sweden's cultural heritage. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:04, 6 February 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24491747 --&gt;

== Tech News: 2023-06 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W06&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/06|Translations]] are available.

'''Recent changes'''
* In the [[mw:Special:MyLanguage/Reading/Web/Desktop Improvements|Vector 2022 skin]], logged-out users using the full-width toggle will be able to see the setting of their choice even after refreshing pages or opening new ones. This only applies to wikis where Vector 2022 is the default. [https://phabricator.wikimedia.org/T321498]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.40/wmf.22|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-02-07|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-02-08|en}}. It will be on all wikis from {{#time:j xg|2023-02-09|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).
* Previously, we announced when some wikis would be in read-only for a few minutes because of a switch of their main database. These switches will not be announced any more, as the read-only time has become non-significant. Switches will continue to happen at 7AM UTC on Tuesdays and Thursdays. [https://phabricator.wikimedia.org/T292543#8568433]
* Across all the wikis, in the Vector 2022 skin, logged-in users will see the page-related links such as &quot;What links here&quot; in a [[mw:Special:MyLanguage/Reading/Web/Desktop_Improvements/Features/Page_tools|new side menu]]. It will be displayed on the other side of the screen. This change had previously been made on Czech, English, and Vietnamese Wikipedias. [https://phabricator.wikimedia.org/T328692]
*[[m:Special:MyLanguage/Community Wishlist Survey 2023|Community Wishlist Survey 2023]] will stop receiving new proposals on [https://zonestamp.toolforge.org/1675706431 Monday, 6 February 2023, at 18:00 UTC]. Proposers should complete any edits by then, to give time for [[m:Special:MyLanguage/Community_Wishlist_Survey/Help_us|translations]] and review. Voting will begin on Friday, 10 February.

'''Future changes'''
* [[File:Octicons-tools.svg|15px|link=|alt=|Advanced item]] Gadgets and user scripts will be changing to load on desktop and mobile sites. Previously they would only load on the desktop site. It is recommended that wiki administrators audit the [[MediaWiki:Gadgets-definition|gadget definitions]] prior to this change, and add &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;skins=…&lt;/code&gt;&lt;/bdi&gt; for any gadgets which should not load on mobile. [https://phabricator.wikimedia.org/T328610 More details are available].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/06|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W06&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 10:21, 6 February 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24491749 --&gt;

== Wikipedia translation of the week: 2023-07 {{User:Xeverything11/tags/updates}} ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Delivery robot]] '''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Woman Takes Groceries from Dax Delivery Robot.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
A '''delivery robot''' is an autonomous robot that provides &quot;last mile&quot; delivery services. An operator may monitor and take control of the robot remotely in certain situations that the robot cannot resolve by itself such as when it is stuck in an obstacle. Delivery robots can be used in different settings such as food delivery, package delivery, hospital delivery, and room service. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:26, 13 February 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24515453 --&gt;

== Tech News: 2023-07 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W07&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/07|Translations]] are available.

'''Problems'''
* On wikis where patrolled edits are enabled, changes made to the [[mw:Special:MyLanguage/Growth/Communities/How to configure the mentors' list|mentor list]] by autopatrolled mentors are not correctly marked as patrolled. It will be fixed later this week. [https://phabricator.wikimedia.org/T328444]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.40/wmf.23|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-02-14|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-02-15|en}}. It will be on all wikis from {{#time:j xg|2023-02-16|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).
* The Reply tool and other parts of [[mw:Special:MyLanguage/Help:DiscussionTools#Mobile|DiscussionTools]] will be deployed for all editors using the mobile site.  You can [[mw:Special:MyLanguage/Talk_pages_project/Mobile#Status_Updates|read more about this decision]]. [https://phabricator.wikimedia.org/T298060]

'''Future changes'''
* All wikis will be read-only for a few minutes on March 1. This is planned for [https://zonestamp.toolforge.org/1677679222 14:00 UTC]. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [https://phabricator.wikimedia.org/T328287][https://phabricator.wikimedia.org/T327920][https://wikitech.wikimedia.org/wiki/Deployments]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/07|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W07&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:49, 14 February 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24540832 --&gt;

== Wikipedia translation of the week: 2023-08 {{User:Xeverything11/tags/updates}} ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Buddha Dhatu Jadi]] '''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Swarno Mandir.JPG|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Buddha Dhatu Jadi''' (Bengali: বুদ্ধ ধাতু জাদি; Burmese: ဗုဒ္ဓဓာတုစေတီ also known as the Bandarban Golden Temple) is located close to Balaghata town, in Bandarban City, in Bangladesh. Dhatu are the material remains of a holy person, and in this temple the relics belong to Buddha. It is the largest Theravada Buddhist temple in Bangladesh and has the second-largest Buddha statue in the country.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:18, 20 February 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24581813 --&gt;

== Tech News: 2023-08 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W08&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/08|Translations]] are available.

'''Problems'''
* Last week, during planned maintenance of Cloud Services, unforeseen complications forced the team to turn off all tools for 2–3 hours to prevent data corruption. Work is ongoing to prevent similar problems in the future. [https://phabricator.wikimedia.org/T329535] 

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.40/wmf.23|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-02-21|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-02-22|en}}. It will be on all wikis from {{#time:j xg|2023-02-23|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).
*The voting phase for the [[m:Special:MyLanguage/Community Wishlist Survey 2023|Community Wishlist Survey 2023]] ends on [https://zonestamp.toolforge.org/1677261621 24 February at 18:00 UTC]. The results of the survey will be announced on 28 February.

'''Future changes'''
* All wikis will be read-only for a few minutes on March 1. This is planned for [https://zonestamp.toolforge.org/1677679222 14:00 UTC]. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [https://phabricator.wikimedia.org/T328287][https://phabricator.wikimedia.org/T327920][https://wikitech.wikimedia.org/wiki/Deployments]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/08|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W08&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:58, 21 February 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24570514 --&gt;

== Wikipedia translation of the week: 2023-09 {{User:Xeverything11/tags/updates}} ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Alina Scholtz]] '''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Alina Scholtz''' (24 September 1908 – 25 February 1996) was a Polish landscape architect, known as one of country's pioneers in developing the field. Throughout her career she worked on various public and private projects for cemeteries, parks and green spaces. Some of her most noted works include the grounds of a villa on Kielecka Street in Warsaw for which she won a Silver Medal at the 1937 World Exhibition in Paris, the memorial cemetery to the victims of the Palmiry massacre, and landscaping projects along the East-West traffic route of Warsaw. In addition to her design work, she served as one of the founding members of the International Federation of Landscape Architects. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:04, 27 February 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24617511 --&gt;

== Tech News: 2023-09 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W09&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/09|Translations]] are available.

'''Problems'''
* Last week, in some areas of the world, there were problems with loading pages for 20 minutes and saving edits for 55 minutes. These issues were caused by a problem with our caching servers due to unforseen events during a routine maintenance task. [https://wikitech.wikimedia.org/wiki/Incidents/2023-02-22_wiki_outage][https://wikitech.wikimedia.org/wiki/Incidents/2023-02-22_read_only] 

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.40/wmf.25|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-02-28|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-03-01|en}}. It will be on all wikis from {{#time:j xg|2023-03-02|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).
* All wikis will be read-only for a few minutes on March 1. This is planned for [https://zonestamp.toolforge.org/1677679222 14:00 UTC]. [https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/Server_switch]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/09|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W09&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:47, 27 February 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24634242 --&gt;

== Wikipedia translation of the week: 2023-10 {{User:Xeverything11/tags/updates}} ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Mary Nzimiro]] '''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Mary Nzimiro''', birthname Mary Nwametu Onumonu, MBE (1898–1993) was a pioneering Nigerian businesswoman, politician and women's activist. In 1948, she was appointed principal representative of the United Africa Company (UAC) for Eastern Nigeria, while maintaining textile and cosmetics retail outlets of her own in Port Harcourt, Aba and Owerri. By the early 1950s, she was among the richest individuals in West Africa, becoming a resident of the exclusive Bernard Carr Street in Port Harcourt. On the political front, she was a member of the influential National Council of Nigeria and the Cameroons, becoming a member of its executive committee in 1957 and vice-president of the NCNC Estern Women's Association in 1962. During the Nigerian Civil War (1967–1970), she organized Igbo women in support of the Biafrans. As a result she lost most of her property in Port Harcourt and returned to her native Oguta where she died in 1993. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:47, 6 March 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24636259 --&gt;

== Tech News: 2023-10 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W10&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/10|Translations]] are available.

'''Recent changes'''
* The Community Wishlist Survey 2023 edition has been concluded. Community Tech has [[m:Special:MyLanguage/Community Wishlist Survey 2023/Results|published the results]] of the survey and will provide an update on what is next in April 2023.
* On wikis which use [[mw:Special:MyLanguage/Writing_systems|LanguageConverter]] to handle multiple writing systems, articles which used custom conversion rules in the wikitext (primarily on Chinese Wikipedia) would have these rules applied inconsistently in the table of contents, especially in the Vector 2022 skin. This has now been fixed. [https://phabricator.wikimedia.org/T306862]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.40/wmf.26|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-03-07|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-03-08|en}}. It will be on all wikis from {{#time:j xg|2023-03-09|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).
* A search system has been added to the [[Special:Preferences|Preferences screen]]. This will let you find different options more easily. Making it work on mobile devices will happen soon. [https://phabricator.wikimedia.org/T313804]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/10|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W10&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:50, 6 March 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24676916 --&gt;

== Wikipedia translation of the week: 2023-11 {{User:Xeverything11/tags/updates}} ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Elizabeth Langdon Williams]] '''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Elizabeth Langdon Williams.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Elizabeth Langdon Williams''' (February 8, 1879 in Putnam, Connecticut – 1981 in Enfield, New Hampshire) was an American human computer and astronomer whose work helped lead to the discovery of Pluto, or Planet X. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:21, 13 March 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24700408 --&gt;

== Tech News: 2023-11 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W11&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/11|Translations]] are available.

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.40/wmf.27|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-03-14|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-03-15|en}}. It will be on all wikis from {{#time:j xg|2023-03-16|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).
* Starting on Wednesday, a new set of Wikipedias will get &quot;[[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]]&quot; ({{int:project-localized-name-cbk_zamwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-cdowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-cewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-cebwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-chwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-chrwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-chywiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ckbwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-cowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-csbwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-cuwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-cvwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-cywiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-itwiki/en}}). This is part of the [[phab:T304110|progressive deployment of this tool to more Wikipedias]]. The communities can [[mw:Special:MyLanguage/Growth/Community configuration|configure how this feature works locally]]. [https://phabricator.wikimedia.org/T304542][https://phabricator.wikimedia.org/T304550] 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/11|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W11&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:20, 13 March 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24700189 --&gt;

== Wikipedia translation of the week: 2023-12 {{User:Xeverything11/tags/updates}} ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:I Didn't Raise My Boy to Be a Soldier]] '''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Peerless Quartet - I Didn't Raise my Boy to be a Soldier.ogg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
an American anti-war song that was influential within the pacifist movement that existed in the United States before it entered World War I. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:31, 20 March 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24720571 --&gt;

== Tech News: 2023-12 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W12&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/12|Translations]] are available.

'''Problems'''
* Last week, some users experienced issues loading image thumbnails. This was due to incorrectly cached images. [https://phabricator.wikimedia.org/T331820]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.1|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-03-21|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-03-22|en}}. It will be on all wikis from {{#time:j xg|2023-03-23|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] A link to the user's [[{{#special:CentralAuth}}]] page will appear on [[{{#special:Contributions}}]] — some user scripts which previously added this link may cause conflicts. This feature request was [[:m:Community Wishlist Survey 2023/Admins and patrollers/Add link to CentralAuth on Special:Contributions|voted #17 in the 2023 Community Wishlist Survey]].
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] The [[{{#special:AbuseFilter}}]] edit window will be resizable and larger by default. This feature request was [[:m:Community Wishlist Survey 2023/Anti-harassment/Make the AbuseFilter edit window resizable and larger by default|voted #80 in the 2023 Community Wishlist Survey]].
* There will be a new option for Administrators when they are unblocking a user, to add the unblocked user’s user page to their watchlist. This will work both via [[{{#special:Unblock}}]] and via the API. [https://phabricator.wikimedia.org/T257662]

'''Meetings'''
* You can join the next meeting with the Wikipedia mobile apps teams. During the meeting, we will discuss the current features and future roadmap. The meeting will be on [https://zonestamp.toolforge.org/1679677204 24 March at 17:00 (UTC)]. See [[mw:Special:MyLanguage/Wikimedia Apps/Office Hours|details and how to join]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/12|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W12&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:26, 21 March 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24732558 --&gt;

== Wikipedia translation of the week: 2023-13 {{User:Xeverything11/tags/updates}} ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:es:Diana Aguavil]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Diana Aguavil]]) ([[:pt:Diana Aguavil]])        ''&lt;/small&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Diana Aguavil.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Diana Alexandra Aguavil Calazacón''' (born 7 August 1983) is an Ecuadorian indigenous leader, since 25 August 2018, the first female governor of the Tsáchila nationality after 104 years of male administrations and winning the 2018 Tsáchila election. She was also the second woman to become a candidate.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:39, 27 March 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24758626 --&gt;

== Tech News: 2023-13 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W13&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/13|Translations]] are available.

'''Recent changes'''
* The [[:mw:Special:MyLanguage/Extension:AbuseFilter|AbuseFilter]] condition limit was increased from 1000 to 2000. [https://phabricator.wikimedia.org/T309609]
* [[:m:Special:MyLanguage/Global AbuseFilter#Locally disabled actions|Some Global AbuseFilter]] actions will no longer apply to local projects. [https://phabricator.wikimedia.org/T332521]
* Desktop users are now able to subscribe to talk pages by clicking on the {{int:discussiontools-newtopicssubscription-button-subscribe-label}} link in the {{int:toolbox}} menu. If you subscribe to a talk page, you receive [[mw:Special:MyLanguage/Notifications|notifications]] when new topics are started on that talk page. This is separate from putting the page on your watchlist or subscribing to a single discussion. [https://phabricator.wikimedia.org/T263821]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.2|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-03-28|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-03-29|en}}. It will be on all wikis from {{#time:j xg|2023-03-30|en}} ([[mw:MediaWiki 1.40/Roadmap|calendar]]).

'''Future changes'''
* You will be able to choose [[mw:Special:MyLanguage/VisualEditor/Diffs|visual diffs]] on all [[m:Special:MyLanguage/Help:Page history|history pages]] at the Wiktionaries and Wikipedias. [https://phabricator.wikimedia.org/T314588]
* [[File:Octicons-tools.svg|15px|link=|alt=|Advanced item]] The legacy [[mw:Mobile Content Service|Mobile Content Service]] is going away in July 2023. Developers are encouraged to switch to Parsoid or another API before then to ensure service continuity. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/4MVQQTONJT7FJAXNVOFV3WWVVMCHRINE/]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/13|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W13&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:14, 28 March 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24780854 --&gt;

== Tech News: 2023-14 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W14&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/14|Translations]] are available.

'''Recent changes'''
* The system for automatically creating categories for the [[mw:Special:MyLanguage/Extension:Babel|Babel]] extension has had several important changes and fixes. One of them allows you to insert templates for automatic category descriptions on creation, allowing you to categorize the new categories. [https://phabricator.wikimedia.org/T211665][https://phabricator.wikimedia.org/T64714][https://phabricator.wikimedia.org/T170654][https://phabricator.wikimedia.org/T184941][https://phabricator.wikimedia.org/T33074]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.3|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-04-04|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-04-05|en}}. It will be on all wikis from {{#time:j xg|2023-04-06|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* Some older [[w:en:Web browser|Web browsers]] will stop being able to use [[w:en:JavaScript|JavaScript]] on Wikimedia wikis from this week. This mainly affects users of Internet Explorer 11. If you have an old web browser on your computer you can try to upgrade to a newer version. [https://phabricator.wikimedia.org/T178356]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The deprecated &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;jquery.hoverIntent&lt;/code&gt;&lt;/bdi&gt; module has been removed. This module could be used by gadgets and user scripts, to create an artificial delay in how JavaScript responds to a hover event. Gadgets and user scripts should now use jQuery &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;hover()&lt;/code&gt;&lt;/bdi&gt; or &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;on()&lt;/code&gt;&lt;/bdi&gt; instead. Examples can be found in the [[mw:Special:MyLanguage/ResourceLoader/Migration_guide_(users)#jquery.hoverIntent|migration guide]]. [https://phabricator.wikimedia.org/T311194]
* Some of the links in [[{{#special:SpecialPages}}]] will be re-arranged. There will be a clearer separation between links that relate to all users, and links related to your own user account. [https://phabricator.wikimedia.org/T333242]
* You will be able to hide the [[mw:Special:MyLanguage/Talk pages project/Replying|Reply button]] in archived discussion pages with a new &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;__ARCHIVEDTALK__&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; magic word.  There will also be a new &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;.mw-archivedtalk&lt;/code&gt;&lt;/bdi&gt; CSS class for hiding the Reply button in individual sections on a page. [https://phabricator.wikimedia.org/T249293][https://phabricator.wikimedia.org/T295553][https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/738221]

'''Future changes'''
* The Vega software that creates data visualizations in pages, such as graphs, will be upgraded to the newest version in the future. Graphs that still use the very old version 1.5 syntax may stop working properly. Most existing uses have been found and updated, but you can help to check, and to update any local documentation. [[phab:T260542|Examples of how to find and fix these graphs are available]]. 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/14|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W14&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:40, 3 April 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24820268 --&gt;

== Tech News: 2023-15 {{User:Xeverything11/tags/updates}} ==

&lt;section begin=&quot;technews-2023-W15&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/15|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] In the visual editor, it is now possible to edit captions of images in galleries without opening the gallery dialog. This feature request was [[:m:Community Wishlist Survey 2023/Editing/Editable gallery captions in Visual Editor|voted #61 in the 2023 Community Wishlist Survey]]. [https://phabricator.wikimedia.org/T190224]
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] You can now receive notifications when another user edits your user page. See the &quot;{{int:Echo-category-title-edit-user-page}}&quot; option in [[Special:Preferences#mw-prefsection-echo|your Preferences]]. This feature request was [[:m:Community Wishlist Survey 2023/Anti-harassment/Notifications for user page edits|voted #3 in the 2023 Community Wishlist Survey]]. [https://phabricator.wikimedia.org/T3876]

'''Problems'''
* There was a problem with all types of CentralNotice banners still being shown to logged-in users even if they had [[Special:Preferences#mw-prefsection-centralnotice-banners|turned off]] specific banner types. This has now been fixed. [https://phabricator.wikimedia.org/T331671]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.4|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-04-11|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-04-12|en}}. It will be on all wikis from {{#time:j xg|2023-04-13|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* Starting on Wednesday, a new set of Wikipedias will get &quot;[[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]]&quot; ({{int:project-localized-name-arywiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-dawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-dinwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-dsbwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-eewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-elwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-emlwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-eowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-etwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-euwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-extwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tumwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ffwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-fiwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-fiu_vrowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-fjwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-fowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-frpwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-frrwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-furwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-gawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-gcrwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-gdwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-glwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-glkwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-gnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-gomwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-gotwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-guwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-gvwiki/en}}). This is part of the [[phab:T304110|progressive deployment of this tool to more Wikipedias]]. The communities can [[mw:Special:MyLanguage/Growth/Community configuration|configure how this feature works locally]]. [https://phabricator.wikimedia.org/T304551][https://phabricator.wikimedia.org/T308133]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/15|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W15&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:05, 10 April 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24851886 --&gt;

== Wikipedia translation of the week: 2023-16 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Lucy Salani]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Lucy Salani]]) ([[:fr:Lucy Salani]])        ''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Lucy Salani.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Lucy Salani''' was an Italian activist and is considered the only Italian transgender person to have survived the Nazi concentration camps.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:06, 17 April 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24872966 --&gt;

== Tech News: 2023-16 ==

&lt;section begin=&quot;technews-2023-W16&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/16|Translations]] are available.

'''Recent changes'''
* You can now see [[mw:Special:MyLanguage/Help:Extension:Kartographer#Show_nearby_articles|nearby articles on a Kartographer map]] with the button for the new feature &quot;{{int:Kartographer-sidebar-nearbybutton}}&quot;. Six wikis have been testing this feature since October. [https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Geoinformation/Nearby_articles#Implementation][https://phabricator.wikimedia.org/T334079]
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] The [[m:Special:GlobalWatchlist|Special:GlobalWatchlist]] page now has links for &quot;{{int:globalwatchlist-markpageseen}}&quot; for each entry. This feature request was [[m:Community Wishlist Survey 2023/Notifications, Watchlists and Talk Pages/Button to mark a single change as read in the global watch list|voted #161 in the 2023 Community Wishlist Survey]]. [https://phabricator.wikimedia.org/T334246]

'''Problems'''
* At Wikimedia Commons, some thumbnails have not been getting replaced correctly after a new version of the image is uploaded. This should be fixed later this week. [https://phabricator.wikimedia.org/T331138][https://phabricator.wikimedia.org/T333042]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] For the last few weeks, some external tools had inconsistent problems with logging-in with OAuth. This has now been fixed. [https://phabricator.wikimedia.org/T332650]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.5|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-04-18|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-04-19|en}}. It will be on all wikis from {{#time:j xg|2023-04-20|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/16|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W16&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:55, 18 April 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24881071 --&gt;

== Wikipedia translation of the week: 2023-17 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:ca:María Fernanda Castro Maya]]'''&lt;br /&gt; &lt;small&gt;''([[:pt:María Fernanda Castro Maya]]) ([[:eu:María Fernanda Castro Maya]])        ''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''María Fernanda Castro Maya''' is a Mexican self-advocate disability rights activist.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:55, 24 April 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24872966 --&gt;

== Tech News: 2023-17 ==

&lt;section begin=&quot;technews-2023-W17&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/17|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] The date-selection menu on pages such as [[{{#special:Contributions}}]] will now show year-ranges that are in the current and past decade, instead of the current and future decade. This feature request was [[m:Community Wishlist Survey 2023/Miscellaneous/Change year range shown in date selection popup|voted #145 in the 2023 Community Wishlist Survey]].  [https://phabricator.wikimedia.org/T334316]

'''Problems'''
* Due to security issues with the [[mw:Special:MyLanguage/Extension:Graph|Graph extension]], graphs have been disabled in all Wikimedia projects. Wikimedia Foundation teams are working to respond to these vulnerabilities. [https://phabricator.wikimedia.org/T334940]
* For a few days, it was not possible to save some kinds of edits on the mobile version of a wiki. This has been fixed. [https://phabricator.wikimedia.org/T334797][https://phabricator.wikimedia.org/T334799][https://phabricator.wikimedia.org/T334794]

'''Changes later this week'''
* All wikis will be read-only for a few minutes on April 26. This is planned for [https://zonestamp.toolforge.org/1682517653 14:00 UTC]. [https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/Server_switch]
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.6|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-04-25|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-04-26|en}}. It will be on all wikis from {{#time:j xg|2023-04-27|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).

'''Future changes'''
* The Editing team plans an A/B test for [[mw:Special:MyLanguage/Talk pages project/Usability|a usability analysis of the Talk page project]]. The [[mw:Special:MyLanguage/Talk pages project/Usability/Analysis|planned measurements are available]]. Your wiki [[phab:T332946|may be invited to participate]]. Please suggest improvements to the measurement plan at [[mw:Talk:Talk pages project/Usability|the discussion page]].
* [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2023-2024|The Wikimedia Foundation annual plan 2023-2024 draft is open for comment and input]] until May 19. The final plan will be published in July 2023 on Meta-wiki.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/17|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W17&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:04, 24 April 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24933592 --&gt;

== Wikipedia translation of the week: 2023-18 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Sonia Orbuch]]'''&lt;br /&gt; &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Sonia Shainwald Orbuch''' (born Sarah Shainwald, May 24, 1925 – September 30, 2018) was an American Holocaust educator. During the Second World War she was a Jewish resistance fighter in eastern Poland.

Orbuch hid in the forests of Poland with her family during the Second World War. She joined a group of Soviet partisans, being renamed Sonia in case she was captured, and helped fight against the Germans. After the war, she returned home, where she met her future husband. After having a daughter in a refugee camp in Germany, the family eventually emigrated to the United States.

She spent the rest of life in public engagement, speaking about her experiences and in 2009, published her autobiography, Here, There Are No Sarahs: A Woman's Courageous Fight Against the Nazis and Her Bittersweet Fulfillment of the American Dream. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 06:24, 1 May 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24872966 --&gt;

== Tech News: 2023-18 ==

&lt;section begin=&quot;technews-2023-W18&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/18|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] The content attribution tools [[mw:Special:MyLanguage/Who Wrote That?|Who Wrote That?]], [[xtools:authorship|XTools Authorship]], and [[xtools:blame|XTools Blame]] now support the French and Italian Wikipedias. More languages will be added in the near future. This is part of the [[m:Community Wishlist Survey 2023/Reading/Extend &quot;Who Wrote That?&quot; tool to more wikis|#7 wish in the 2023 Community Wishlist Survey]]. [https://phabricator.wikimedia.org/T243711][https://phabricator.wikimedia.org/T270490][https://phabricator.wikimedia.org/T334891]
* The [[:commons:Special:MyLanguage/Commons:Video2commons|Video2commons]] tool has been updated. This fixed several bugs related to YouTube uploads. [https://github.com/toolforge/video2commons/pull/162/commits]
* The [[{{#special:Preferences}}]] page has been redesigned on mobile web. The new design makes it easier to browse the different categories and settings at low screen widths. You can also now access the page via a link in the Settings menu in the mobile web sidebar. [https://www.mediawiki.org/wiki/Moderator_Tools/Content_moderation_on_mobile_web/Preferences]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.7|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-05-02|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-05-03|en}}. It will be on all wikis from {{#time:j xg|2023-05-04|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/18|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W18&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:45, 2 May 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24966974 --&gt;

== Wikipedia translation of the week: 2023-19 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Nadia Ghulam]]'''&lt;br /&gt;&lt;small&gt;''([[:fr:Nadia Ghulam]]) ([[:es:Nadia Ghulam]]) ([[:ca:Nadia Ghulam]])''&lt;/small&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Nadia Ghulam (cropped).jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Nadia Ghulam Dastgir''' is an Afghan woman who spent ten years posing as her dead brother to evade the Taliban's strictures against women. Her book about her experiences, written with Agnès Rotger and published in 2010, El secret del meu turbant (The Secret of My Turban), won the Prudenci Bertrana Prize for fiction. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:37, 8 May 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=24966177 --&gt;

== Tech News: 2023-19 ==

&lt;section begin=&quot;technews-2023-W19&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/19|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] Last week, Community Tech released the first update for providing [[m:Special:MyLanguage/Community Wishlist Survey 2022/Better diff handling of paragraph splits|better diffs]], the #1 request in the 2022 Community Wishlist Survey. [[phab:T324759|This update]] adds legends and tooltips to inline diffs so that users unfamiliar with the blue and yellow highlights can better understand the type of edits made.
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] When you close an image that is displayed via MediaViewer, it will now return to the wiki page instead of going back in your browser history. This feature request was [[m:Community Wishlist Survey 2023/Reading/Return to the article when closing the MediaViewer|voted #65 in the 2023 Community Wishlist Survey]]. [https://phabricator.wikimedia.org/T236591]
* The [[mw:Special:MyLanguage/Extension:SyntaxHighlight|SyntaxHighlight]] extension now supports &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;wikitext&lt;/code&gt;&lt;/bdi&gt; as a selected language. Old alternatives that were used to highlight wikitext, such as &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;html5&lt;/code&gt;&lt;/bdi&gt;, &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;moin&lt;/code&gt;&lt;/bdi&gt;, and &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;html+handlebars&lt;/code&gt;&lt;/bdi&gt;, can now be replaced. [https://phabricator.wikimedia.org/T29828]
* [[mw:Special:MyLanguage/Manual:Creating pages with preloaded text|Preloading text to new pages/sections]] now supports preloading from localized MediaWiki interface messages. [https://cs.wikipedia.org/wiki/User_talk:Martin_Urbanec_(WMF)?action=edit&amp;section=new&amp;preload=MediaWiki:July Here is an example] at the {{int:project-localized-name-cswiki/en}} that uses &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;preload=MediaWiki:July&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;. [https://phabricator.wikimedia.org/T330337]

'''Problems'''
* Graph Extension update: Foundation developers have completed upgrading the visualization software to Vega5. Existing community graphs based on Vega2 are no longer compatible. Communities need to update local graphs and templates, and shared lua modules like &lt;bdi lang=&quot;de&quot; dir=&quot;ltr&quot;&gt;[[:de:Modul:Graph]]&lt;/bdi&gt;. The [https://vega.github.io/vega/docs/porting-guide/ Vega Porting guide] provides the most comprehensive detail on migration from Vega2 and [https://www.mediawiki.org/w/index.php?title=Template:Graph:PageViews&amp;action=history here is an example migration]. Vega5 has currently just been enabled on mediawiki.org to provide a test environment for communities. [https://phabricator.wikimedia.org/T334940#8813922]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.8|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-05-09|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-05-10|en}}. It will be on all wikis from {{#time:j xg|2023-05-11|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Until now, all new OAuth apps went through manual review. Starting this week, apps using identification-only or basic authorizations will not require review. [https://phabricator.wikimedia.org/T67750]

'''Future changes'''
* During the next year, MediaWiki will stop using IP addresses to identify logged-out users, and will start automatically assigning unique temporary usernames. Read more at [[m:Special:MyLanguage/IP Editing: Privacy Enhancement and Abuse Mitigation/Updates|IP Editing: Privacy Enhancement and Abuse Mitigation/Updates]]. You can [[m:Talk:IP Editing: Privacy Enhancement and Abuse Mitigation#What should it look like?|join the discussion]] about the [[m:Special:MyLanguage/IP Editing: Privacy Enhancement and Abuse Mitigation/Updates#What will temporary usernames look like?|format of the temporary usernames]]. [https://phabricator.wikimedia.org/T332805]
* There will be an [[:w:en:A/B testing|A/B test]] on 10 Wikipedias where the Vector 2022 skin is the default skin. Half of logged-in desktop users will see an interface where the different parts of the page are more clearly separated. You can [[mw:Special:MyLanguage/Reading/Web/Desktop Improvements/Updates/2023-05 Zebra9 A/B test|read more]]. [https://phabricator.wikimedia.org/T333180][https://phabricator.wikimedia.org/T335972]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] &lt;code&gt;jquery.tipsy&lt;/code&gt; will be removed from the MediaWiki core. This will affect some user scripts. Many lines with &lt;code&gt;.tipsy(&lt;/code&gt; can be commented out. &lt;code&gt;OO.ui.PopupWidget&lt;/code&gt; can be used to keep things working like they are now. You can [[phab:T336019|read more]] and [[:mw:Help:Locating broken scripts|read about how to find broken scripts]]. [https://phabricator.wikimedia.org/T336019]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/19|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W19&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:36, 9 May 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=24998636 --&gt;

== Wikipedia translation of the week: 2023-20 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Purple Day]]'''&lt;br /&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Epilepsy Warrior Brooch May 2018 Purple Day.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Purple Day''' is a global grassroots event that was formed with the intention to increase worldwide awareness of epilepsy, and to dispel common myths and fears of this neurological disorder. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:17, 15 May 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25000361 --&gt;

== Tech News: 2023-20 ==

&lt;section begin=&quot;technews-2023-W20&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/20|Translations]] are available.

'''Problems'''
* Citations that are automatically generated based on [[d:Q33057|ISBN]] are currently broken. This affects citations made with the [[mw:Special:MyLanguage/Help:VisualEditor/User_guide/Citations-Full#Automatic|VisualEditor Automatic tab]], and the use of the citoid API in gadgets and user scripts. Work is ongoing to restore this feature. [https://phabricator.wikimedia.org/T336298] 

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.9|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-05-16|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-05-17|en}}. It will be on all wikis from {{#time:j xg|2023-05-18|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* Starting on Wednesday, a new set of Wikipedias will get &quot;[[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]]&quot; ({{int:project-localized-name-gorwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hakwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hawwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hifwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hrwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hsbwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-htwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-iawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-iewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-igwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ilowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-inhwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-iowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-iswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-iuwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-jamwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-jvwiki/en}}). This is part of the [[phab:T304110|progressive deployment of this tool to more Wikipedias]]. The communities can [[mw:Special:MyLanguage/Growth/Community configuration|configure how this feature works locally]]. [https://phabricator.wikimedia.org/T308134] 

'''Future changes'''
* There is a recently formed team at the Wikimedia Foundation which will be focusing on experimenting with new tools. Currently they are building [[m:Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/Future_Audiences#FA2.2_Conversational_AI|a prototype ChatGPT plugin that allows information generated by ChatGPT to be properly attributed]] to the Wikimedia projects.
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Gadget and userscript developers should replace &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;jquery.cookie&lt;/code&gt;&lt;/bdi&gt; with &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;mediawiki.cookie&lt;/code&gt;&lt;/bdi&gt;. The &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;jquery.cookie&lt;/code&gt;&lt;/bdi&gt; library will be removed in ~1 month, and staff developers will run a script to replace any remaining uses at that time. [https://phabricator.wikimedia.org/T336018]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/20|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W20&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:45, 15 May 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25011501 --&gt;

== Tech News: 2023-21 ==

&lt;section begin=&quot;technews-2023-W21&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/21|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] The &quot;recent edits&quot; time period for page watchers is now 30 days. It used to be 180 days. This was a [[m:Community Wishlist Survey 2023/Notifications, Watchlists and Talk Pages/Change information about the number of watchers on a page|Community Wishlist Survey proposal]]. [https://phabricator.wikimedia.org/T336250]

'''Changes later this week'''
* An [[mw:special:MyLanguage/Growth/Positive reinforcement#Impact|improved impact module]] will be available at Wikipedias. The impact module is a feature available to newcomers [[mw:Special:MyLanguage/Growth/Feature summary#Newcomer homepage|at their personal homepage]]. It will show their number of edits, how many readers their edited pages have, how many thanks they have received and similar things. It is also accessible by accessing Special:Impact. [https://phabricator.wikimedia.org/T336203]
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.10|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-05-23|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-05-24|en}}. It will be on all wikis from {{#time:j xg|2023-05-25|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/21|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W21&quot;/&gt;

16:55, 22 May 2023 (UTC)
&lt;!-- Message sent by User:Trizek (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25028325 --&gt;

== Wikipedia translation of the week: 2023-22 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Valencian Art Nouveau]]'''&lt;br /&gt; &lt;small&gt;''([[:es:Modernismo valenciano]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Santuario Novelda.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Valencian Art Nouveau''' (Spanish: modernismo valenciano, Valencian: modernisme valencià), is the historiographic denomination given to an art and literature movement associated with the Art Nouveau in the Valencian Community, in Spain.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:46, 29 May 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25074014 --&gt;

== Tech News: 2023-22 ==

&lt;section begin=&quot;technews-2023-W22&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/22|Translations]] are available.

'''Recent changes'''
* Citations can once again be added automatically from ISBNs, thanks to Zotero's ISBN searches. The current data sources are the Library of Congress (United States), the Bibliothèque nationale de France (French National Library), and K10plus ISBN (German repository). Additional data source searches can be [[mw:Citoid/Creating Zotero translators|proposed to Zotero]]. The ISBN labels in the [[mw:Special:MyLanguage/Help:VisualEditor/User_guide/Citations-Full#Automatic|VisualEditor Automatic tab]] will reappear later this week. [https://phabricator.wikimedia.org/T336298#8859917]
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] The page [[{{#special:EditWatchlist}}]] now has &quot;{{int:watchlistedit-normal-check-all}}&quot; options to select all the pages within a namespace. This feature request was [[m:Community Wishlist Survey 2023/Notifications, Watchlists and Talk Pages/Watchlist edit - &quot;check all&quot; checkbox|voted #161 in the 2023 Community Wishlist Survey]]. [https://phabricator.wikimedia.org/T334252]	

'''Problems'''
* For a few days earlier this month, the &quot;Add interlanguage link&quot; item in the Tools menu did not work properly. This has now been fixed. [https://phabricator.wikimedia.org/T337081]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.11|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-05-30|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-05-31|en}}. It will be on all wikis from {{#time:j xg|2023-06-01|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* VisualEditor will be switched to a new backend on [https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/dblists/small.dblist small] and [https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/dblists/medium.dblist medium] wikis this week. Large wikis will follow in the coming weeks. This is part of the effort to move Parsoid into MediaWiki core. The change should have no noticeable effect on users, but if you experience any slow loading or other strangeness when using VisualEditor, please report it on the phabricator ticket linked here. [https://phabricator.wikimedia.org/T320529]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/22|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W22&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:04, 29 May 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25079963 --&gt;

== Wikipedia translation of the week: 2023-23 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:pt:Alessandra Korap]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Alessandra Korap]])         ''&lt;/small&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Alessandra Korap''' is an indigenous leader and Brazilian environmental activist from the Munduruku ethnic group. Her main work is defending the demarcation of indigenous territory and denouncing the illegal exploitation and activities of the mining and logging industries. Alessandra is internationally recognized for her work.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:33, 5 June 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25111481 --&gt;

== Tech News: 2023-23 ==

&lt;section begin=&quot;technews-2023-W23&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/23|Translations]] are available.

'''Recent changes'''
* The [[:mw:Special:MyLanguage/Help:Extension:RealMe|RealMe]] extension allows you to mark URLs on your user page as verified for Mastodon and similar software.
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] Citation and footnote editing can now be started from the reference list when using the visual editor. This feature request was [[m:Community Wishlist Survey 2023/Citations/Allow citations to be edited in the references section with VisualEditor|voted #2 in the 2023 Community Wishlist Survey]]. [https://phabricator.wikimedia.org/T54750]
* Previously, clicking on someone else's link to Recent Changes with filters applied within the URL could unintentionally change your preference for &quot;{{int:Rcfilters-group-results-by-page}}&quot;. This has now been fixed. [https://phabricator.wikimedia.org/T202916#8874081]

'''Problems'''
* For a few days last week, some tools and bots returned outdated information due to database replication problems, and may have been down entirely while it was being fixed. These issues have now been fixed. [https://phabricator.wikimedia.org/T337446]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.12|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-06-06|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-06-07|en}}. It will be on all wikis from {{#time:j xg|2023-06-08|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* Bots will no longer be prevented from making edits because of URLs that match the [[mw:Special:MyLanguage/Extension:SpamBlacklist|spam blacklist]]. [https://phabricator.wikimedia.org/T313107]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/23|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W23&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:52, 5 June 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25114640 --&gt;

== Wikipedia translation of the week: 2023-24 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Cassinga Day]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Cassinga Day''' is a national public holiday in Namibia remembering the Cassinga Massacre. Commemorated annually on 4 May, the date &quot;remembers those (approximately 600) killed in 1978 when the South African Defence Force attacked a SWAPO base at Cassinga in southern Angola&quot;. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:07, 12 June 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25111481 --&gt;

== Tech News: 2023-24 ==

&lt;section begin=&quot;technews-2023-W24&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/24|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] The content attribution tools [[mw:Special:MyLanguage/Who Wrote That?|Who Wrote That?]], [[xtools:authorship|XTools Authorship]], and [[xtools:blame|XTools Blame]] now support the Dutch, German, Hungarian, Indonesian, Japanese, Polish and Portuguese Wikipedias. This was the [[m:Community Wishlist Survey 2023/Reading/Extend &quot;Who Wrote That?&quot; tool to more wikis|#7 wish in the 2023 Community Wishlist Survey]]. [https://phabricator.wikimedia.org/T334891]
* The [[mw:Special:MyLanguage/Structured Data Across Wikimedia/Search Improvements#Search Preview panel|Search Preview panel]] has been deployed on four Wikipedias (Catalan, Dutch, Hungarian and Norwegian). The panel will show an image related to the article (if existing), the top sections of the article, related images (coming from MediaSearch on Commons), and eventually the sister projects associated with the article. [https://phabricator.wikimedia.org/T306341]
* The [[:mw:Special:MyLanguage/Help:Extension:RealMe#Verifying_a_link_on_non-user_pages|RealMe]] extension now allows administrators to verify URLs for any page, for Mastodon and similar software. [https://phabricator.wikimedia.org/T324937]
* The default project license [https://lists.wikimedia.org/hyperkitty/list/wikimediaannounce-l@lists.wikimedia.org/thread/7G6XPWZPQFLZ2JANN3ZX6RT4DVUI3HZQ/ has been officially upgraded] to CC BY-SA 4.0. The software interface messages have been updated. Communities should feel free to start updating any mentions of the old CC BY-SA 3.0 licensing within policies and related documentation pages. [https://phabricator.wikimedia.org/T319064]

'''Problems'''
* For three days last month, some Wikipedia pages edited with VisualEditor or DiscussionTools had an unintended &lt;code&gt;&lt;nowiki&gt;__TOC__&lt;/nowiki&gt;&lt;/code&gt; (or its localized form) added during an edit. There is [[mw:Parsoid/Deployments/T336101_followup|a listing of affected pages sorted by wiki]], that may still need to be fixed. [https://phabricator.wikimedia.org/T336101]
* Currently, the &quot;{{int:Visualeditor-dialog-meta-categories-defaultsort-label}}&quot; feature in VisualEditor is broken. Existing &lt;code&gt;&lt;nowiki&gt;{{DEFAULTSORT:...}}&lt;/nowiki&gt;&lt;/code&gt; keywords incorrectly appear as missing templates in VisualEditor. Developers are exploring how to fix this. In the meantime, those wishing to edit the default sortkey of a page are advised to switch to source editing. [https://phabricator.wikimedia.org/T337398]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Last week, an update to the delete form may have broken some gadgets or user scripts. If you need to manipulate (empty) the reason field, replace &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;#wpReason&lt;/code&gt;&lt;/bdi&gt; with &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot; style=&quot;white-space: nowrap;&quot;&gt;&lt;code&gt;#wpReason &gt; input&lt;/code&gt;&lt;/bdi&gt;. See [https://cs.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-CleanDeleteReasons.js&amp;diff=22859956&amp;oldid=12794189 an example fix]. [https://phabricator.wikimedia.org/T337809]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.13|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-06-13|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-06-14|en}}. It will be on all wikis from {{#time:j xg|2023-06-15|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* VisualEditor will be switched to a new backend on English Wikipedia on Monday, and all other [https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/dblists/large.dblist large] wikis on Thursday. The change should have no noticeable effect on users, but if you experience any slow loading or other strangeness when using VisualEditor, please report it on the phabricator ticket linked here. [https://phabricator.wikimedia.org/T320529]

'''Future changes'''
* From 5 June to 17 July, the Foundation's [[:mw:Wikimedia Security Team|Security team]] is holding a consultation with contributors regarding a draft policy to govern the use of third-party resources in volunteer-developed gadgets and scripts. Feedback and suggestions are warmly welcome at [[m:Special:MyLanguage/Third-party resources policy|Third-party resources policy]] on meta-wiki.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/24|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W24&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 14:52, 12 June 2023 (UTC)
&lt;!-- Message sent by User:Trizek (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25133779 --&gt;

== Tech News: 2023-25 ==

&lt;section begin=&quot;technews-2023-W25&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/25|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Flame graphs are now available in WikimediaDebug. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/JXNQD3EHG5V5QW5UXFDPSHQG4MJ3FWJQ/][https://techblog.wikimedia.org/2023/06/08/flame-graphs-arrive-in-wikimediadebug/]

'''Changes later this week'''
* There is no new MediaWiki version this week.
* There is now a toolbar search popup in the visual editor. You can trigger it by typing &lt;code&gt;\&lt;/code&gt; or pressing &lt;code&gt;ctrl + shift + p&lt;/code&gt;. It can help you quickly access most tools in the editor. [https://commons.wikimedia.org/wiki/File:Visual_editor_toolbar_search_feature.png][https://phabricator.wikimedia.org/T66905]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/25|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W25&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:09, 19 June 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25159510 --&gt;

== Wikipedia translation of the week: 2023-26 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Rawon]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Rawon Setan.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Rawon''' (Javanese: ꦫꦮꦺꦴꦤ꧀) is an Indonesian beef soup. Originating from East Java, rawon utilizes the black keluak nut as the main seasoning, which gives a dark color and nutty flavor to the soup. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:18, 26 June 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25177056 --&gt;

== Tech News: 2023-26 ==

&lt;section begin=&quot;technews-2023-W26&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/26|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The Action API modules and Special:LinkSearch will now add a trailing &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;/&lt;/code&gt;&lt;/bdi&gt; to all &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;prop=extlinks&lt;/code&gt;&lt;/bdi&gt; responses for bare domains. This is part of the work to remove duplication in the &lt;code&gt;externallinks&lt;/code&gt; database table. [https://phabricator.wikimedia.org/T337994]

'''Problems'''
* Last week, search was broken on Commons and Wikidata for 23 hours. [https://phabricator.wikimedia.org/T339810][https://wikitech.wikimedia.org/wiki/Incidents/2023-06-18_search_broken_on_wikidata_and_commons]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.15|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-06-27|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-06-28|en}}. It will be on all wikis from {{#time:j xg|2023-06-29|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The Minerva skin now applies more predefined styles to the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;.mbox-text&lt;/code&gt;&lt;/bdi&gt; CSS class. This enables support for mbox templates that use divs instead of tables. Please make sure that the new styles won't affect other templates in your wiki. [https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/930901/][https://phabricator.wikimedia.org/T339040]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Gadgets will now load on both desktop and mobile by default. Previously, gadgets loaded only on desktop by default. Changing this default using the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;|targets=&lt;/code&gt;&lt;/bdi&gt; parameter is also deprecated and should not be used. You should make gadgets work on mobile or disable them based on the skin (with the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;|skins=&lt;/code&gt;&lt;/bdi&gt; parameter in &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;MediaWiki:Gadgets-definition&lt;/bdi&gt;) rather than whether the user uses the mobile or the desktop website. Popular gadgets that create errors on mobile will be disabled by developers on the Minerva skin as a temporary solution. [https://phabricator.wikimedia.org/T127268]
* All namespace tabs now have the same browser [[m:Special:MyLanguage/Help:Keyboard_shortcuts|access key]] by default. Previously, custom and extension-defined namespaces would have to have their access keys set manually on-wiki, but that is no longer necessary. [https://phabricator.wikimedia.org/T22126]
* The review form of the Flagged Revisions extension now uses the standardized [[mw:Special:MyLanguage/Codex|user interface components]]. [https://phabricator.wikimedia.org/T191156]

'''Future changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] How media is structured in the parser's HTML output will change in the coming weeks at [[:wikitech:Deployments/Train#Thursday|group2 wikis]]. This change improves the accessibility of content. You may need to update your site-CSS, or userscripts and gadgets. There are [[mw:Special:MyLanguage/Parsoid/Parser_Unification/Media_structure/FAQ|details on what code to check, how to update the code, and where to report any related problems]]. [https://phabricator.wikimedia.org/T314318]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/26|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W26&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 16:19, 26 June 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25202311 --&gt;

== Wikipedia translation of the week: 2023-27 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Hook echo]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Tornadic classic supercell radar.gif|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
A '''hook echo''' is a pendant or hook-shaped weather radar signature as part of some supercell thunderstorms. It is found in the lower portions of a storm as air and precipitation flow into a mesocyclone, resulting in a curved feature of reflectivity. The echo is produced by rain, hail, or even debris being wrapped around the supercell 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:18, 3 July 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25241057 --&gt;

== Tech News: 2023-27 ==

&lt;section begin=&quot;technews-2023-W27&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/27|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] As part of the rolling out of the [[m:Community Wishlist Survey 2022/Multimedia and Commons/Audio links that play on click|audio links that play on click]] wishlist proposal, [https://noc.wikimedia.org/conf/highlight.php?file=dblists/small.dblist small wikis] will now be able to use the [[mw:Special:MyLanguage/Help:Extension:Phonos#Inline audio player mode|inline audio player]] that is implemented by the [[mw:Extension:Phonos|Phonos]] extension. [https://phabricator.wikimedia.org/T336763]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] From this week all gadgets automatically load on mobile and desktop sites. If you see any problems with gadgets on your wikis, please adjust the [[mw:Special:MyLanguage/Extension:Gadgets#Options|gadget options]] in your gadget definitions file. [https://phabricator.wikimedia.org/T328610]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.16|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-07-04|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-07-05|en}}. It will be on all wikis from {{#time:j xg|2023-07-06|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/27|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W27&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:51, 3 July 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25231546 --&gt;

== Tech News: 2023-28 ==

&lt;section begin=&quot;technews-2023-W28&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/28|Translations]] are available.

'''Recent changes'''
* The [[:mw:Special:MyLanguage/Structured Data Across Wikimedia/Section-level Image Suggestions|Section-level Image Suggestions feature]] has been deployed on seven Wikipedias (Portuguese, Russian, Indonesian, Catalan, Hungarian, Finnish and Norwegian Bokmål). The feature recommends images for articles on contributors' watchlists that are a good match for individual sections of those articles.
* [[:m:Special:MyLanguage/Global AbuseFilter|Global abuse filters]] have been enabled on all Wikimedia projects, except English and Japanese Wikipedias (who opted out). This change was made following a [[:m:Requests for comment/Make global abuse filters opt-out|global request for comments]]. [https://phabricator.wikimedia.org/T341159]
* [[{{#special:BlockedExternalDomains}}]] is a new tool for administrators to help fight spam. It provides a clearer interface for blocking plain domains (and their subdomains), is more easily searchable, and is faster for the software to process for each edit on the wiki. It does not support regex (for complex cases), nor URL path-matching, nor the [[MediaWiki:Spam-whitelist|MediaWiki:Spam-whitelist]], but otherwise it replaces most of the functionalities of the existing [[MediaWiki:Spam-blacklist|MediaWiki:Spam-blacklist]]. There is a Python script to help migrate all simple domains into this tool, and more feature details, within [[mw:Special:MyLanguage/Manual:BlockedExternalDomains|the tool's documentation]]. It is available at all wikis except for Meta-wiki, Commons, and Wikidata. [https://phabricator.wikimedia.org/T337431]
* The WikiEditor extension was updated. It includes some of the most frequently used features of wikitext editing. In the past, many of its messages could only be translated by administrators, but now all regular translators on translatewiki can translate them. Please check [https://translatewiki.net/wiki/Special:MessageGroupStats?group=ext-wikieditor&amp;messages=&amp;x=D#sortable:0=asc the state of WikiEditor localization into your language], and if the &quot;Completion&quot; for your language shows anything less than 100%, please complete the translation. See [https://lists.wikimedia.org/hyperkitty/list/wikitech-ambassadors@lists.wikimedia.org/thread/D4YELU2DXMZ75PGELUOKXXMFF3FH45XA/ a more detailed explanation].

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.17|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-07-11|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-07-12|en}}. It will be on all wikis from {{#time:j xg|2023-07-13|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* The default protocol of [[{{#special:LinkSearch}}]] and API counterparts has changed from http to both http and https. [https://phabricator.wikimedia.org/T14810]
* [[{{#special:LinkSearch}}]] and its API counterparts will now search for all of the URL provided in the query. It used to be only the first 60 characters. This feature was requested fifteen years ago. [https://phabricator.wikimedia.org/T17218]

'''Future changes'''
* There is an experiment with a [[:w:en:ChatGPT|ChatGPT]] plugin. This is to show users where the information is coming from when they read information from Wikipedia. It has been tested by Wikimedia Foundation staff and other Wikimedians. Soon all ChatGPT plugin users can use the Wikipedia plugin. This is the same plugin which was mentioned in [[m:Special:MyLanguage/Tech/News/2023/20|Tech News 2023/20]]. [https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/Future_Audiences#FA2.2_Conversational_AI]
* There is an ongoing discussion on a [[m:Special:MyLanguage/Third-party resources policy|proposed Third-party resources policy]]. The proposal will impact the use of third-party resources in gadgets and userscripts. Based on the ideas received so far, policy includes some of the risks related to user scripts and gadgets loading third-party resources, some best practices and exemption requirements such as code transparency and inspectability. Your feedback and suggestions are warmly welcome until July 17, 2023 on [[m:Talk:Third-party resources policy|on the policy talk page]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/28|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W28&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:54, 10 July 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25278797 --&gt;

== Wikipedia translation of the week: 2023-29 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Esther Cooper Jackson]]'''&lt;br /&gt; &lt;small&gt;''([[:fr:Esther Cooper Jackson]]) ([[:simple:Esther Cooper Jackson]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Esther Cooper Jackson, 1968, Great Barrington.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Esther Victoria Cooper Jackson''' was an American civil rights activist and social worker. She was one of the founding editors of the magazine Freedomways. She also was an organizational and executive secretary at the Southern Negro Youth Congress.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:14, 17 July 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25266525 --&gt;

== Tech News: 2023-29 ==

&lt;section begin=&quot;technews-2023-W29&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/29|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] We are now serving 1% of all global user traffic from [[w:en:Kubernetes|Kubernetes]] (you can [[wikitech:MediaWiki On Kubernetes|read more technical details]]). We are planning to increment this percentage regularly. You can [[phab:T290536|follow the progress of this work]]. 

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.18|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-07-18|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-07-19|en}}. It will be on all wikis from {{#time:j xg|2023-07-20|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] MediaWiki [[mw:Special:MyLanguage/Help:System_message|system messages]] will now look for available local fallbacks, instead of always using the default fallback defined by software. This means wikis no longer need to override each language on the [[mw:Special:MyLanguage/Manual:Language#Fallback_languages|fallback chain]] separately. For example, English Wikipedia doesn't have to create &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;en-ca&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;en-gb&lt;/code&gt;&lt;/bdi&gt; subpages with a transclusion of the base pages anymore. This makes it easier to maintain local overrides. [https://phabricator.wikimedia.org/T229992]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;action=growthsetmentorstatus&lt;/code&gt;&lt;/bdi&gt; API will be deprecated with the new MediaWiki version. Bots or scripts calling that API should use the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;action=growthmanagementorlist&lt;/code&gt;&lt;/bdi&gt; API now. [https://phabricator.wikimedia.org/T321503]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/29|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W29&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:08, 17 July 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25289122 --&gt;

== Wikipedia translation of the week: 2023-30 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Cut of pork]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:American Pork Cuts.svg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''cuts of pork''' are the different parts of the pig which are consumed as food by humans. The terminology and extent of each cut varies from country to country. There are between four and six primal cuts, which are the large parts in which the pig is first cut: the shoulder (blade and picnic), loin, belly (spare ribs and side) and leg 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:21, 24 July 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25318972 --&gt;

== Tech News: 2023-30 ==

&lt;section begin=&quot;technews-2023-W30&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/30|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]]   On July 18, the Wikimedia Foundation launched a survey about the [[:mw:Technical_decision_making|technical decision making process]] for people who do technical work that relies on software that is maintained by the Foundation or affiliates. If this applies to you, [https://wikimediafoundation.limesurvey.net/885471 please take part in the survey]. The survey will be open for three weeks, until August 7. You can find more information in [[listarchive:list/wikitech-l@lists.wikimedia.org/thread/Q7DUCFA75DXG3G2KHTO7CEWMLCYTSDB2/|the announcement e-mail on wikitech-l]].

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.19|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-07-25|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-07-26|en}}. It will be on all wikis from {{#time:j xg|2023-07-27|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/30|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W30&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 02:20, 25 July 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25332248 --&gt;

== Wikipedia translation of the week: 2023-31 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Gunhild Cross]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Gunhildkorset.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Gunhild Cross''' (Danish: Gunhildkorset), named for its first owner, Gunhild, a daughter of Svend III of Denmark, is a mid-12th-century crucifix carved in walrus tusk and with both Latin and Runic inscriptions. It is now in the collection of the National Museum of Denmark. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:48, 31 July 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25380210 --&gt;

== Tech News: 2023-31 ==

&lt;section begin=&quot;technews-2023-W31&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/31|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The [[mw:Synchronizer|Synchronizer]] tool is now available to keep Lua modules synced across Wikimedia wikis, along with [[mw:Multilingual Templates and Modules|updated documentation]] to develop global Lua modules and templates.
* The tag filter on [[{{#special:NewPages}}]] and revision history pages can now be inverted. For example, you can hide edits that were made using an automated tool. [https://phabricator.wikimedia.org/T334337][https://phabricator.wikimedia.org/T334338]
* The Wikipedia [[:w:en:ChatGPT|ChatGPT]] plugin experiment can now be used by ChatGPT users who can use plugins. You can participate in a [[:m:Talk:Wikimedia Foundation Annual Plan/2023-2024/Draft/Future Audiences#Announcing monthly Future Audiences open &quot;office hours&quot;|video call]] if you want to talk about this experiment or similar work. [https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/Future_Audiences#FA2.2_Conversational_AI]

'''Problems'''
* It was not possible to generate a PDF for pages with non-Latin characters in the title, for the last two weeks. This has now been fixed. [https://phabricator.wikimedia.org/T342442]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.20|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-08-01|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-08-02|en}}. It will be on all wikis from {{#time:j xg|2023-08-03|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* Starting on Tuesday, a new set of Wikipedias will get &quot;[[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]]&quot; ({{int:project-localized-name-kawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kaawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kabwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kbdwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kbpwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kiwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kkwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kmwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-knwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kshwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kuwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kwwiki/en}}). This is part of the [[phab:T304110|progressive deployment of this tool to more Wikipedias]]. The communities can [[mw:Special:MyLanguage/Growth/Community configuration|configure how this feature works locally]]. [https://phabricator.wikimedia.org/T308135] 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/31|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W31&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:54, 31 July 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25362228 --&gt;

== Wikipedia translation of the week: 2023-32 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Polyura athamas]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Close wing mud-puddling position of Charaxes bharata (C.&amp; R. Felder,1867) - Indian Nawab.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''Polyura athamas''''', the common nawab, is a species of fast-flying canopy butterfly found in tropical Asia. It belongs to the Charaxinae (rajahs and nawabs) in the brush-footed butterfly family (Nymphalidae). 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 03:14, 7 August 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25410866 --&gt;

== Tech News: 2023-32 ==

&lt;section begin=&quot;technews-2023-W32&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/32|Translations]] are available.

'''Recent changes'''
* Mobile Web editors can now [[mw:Special:MyLanguage/Reading/Web/Advanced_mobile_contributions#August_1,_2023_-_Full-page_editing_added_on_mobile|edit a whole page at once]]. To use this feature, turn on &quot;{{int:Mobile-frontend-mobile-option-amc}}&quot; in your settings and use the &quot;{{int:Minerva-page-actions-editfull}}&quot; button in the &quot;{{int:Minerva-page-actions-overflow}}&quot; menu. [https://phabricator.wikimedia.org/T203151]

'''Changes later this week'''
* There is no new MediaWiki version this week.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/32|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W32&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:21, 7 August 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25420038 --&gt;

== Wikipedia translation of the week: 2023-33 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Women's page]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:&quot;Doings in Pittsburg Society&quot; The Pittsburg Press February 1, 1920.png|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''women's page''' (sometimes called home page or women's section) of a newspaper was a section devoted to covering news assumed to be of interest to women. Women's pages started out in the 19th century as society pages and eventually morphed into features sections in the 1970s. Although denigrated during much of that period, they had a significant impact on journalism and in their communities. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:51, 14 August 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25427472 --&gt;

== Tech News: 2023-33 ==

&lt;section begin=&quot;technews-2023-W33&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/33|Translations]] are available.

'''Recent changes'''
* The Content translation system is no longer using Youdao's [[mw:Special:MyLanguage/Help:Content_translation/Translating/Initial_machine_translation|machine translation service]]. The service was in place for several years, but due to no usage, and availability of alternatives, it was deprecated to reduce maintenance overheads. Other services which cover the same languages are still available. [https://phabricator.wikimedia.org/T329137]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.22|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-08-15|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-08-16|en}}. It will be on all wikis from {{#time:j xg|2023-08-17|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* Starting on Wednesday, a new set of Wikipedias will get &quot;[[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]]&quot; ({{int:project-localized-name-lawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ladwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-lbwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-lbewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-lezwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-lfnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-lgwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-liwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-lijwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-lmowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-lnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ltgwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-lvwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-maiwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-map_bmswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mdfwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mgwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hywiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kywiki/en}}). This is part of the [[phab:T304110|progressive deployment of this tool to more Wikipedias]]. The communities can [[mw:Special:MyLanguage/Growth/Community configuration|configure how this feature works locally]]. [https://phabricator.wikimedia.org/T308136] &lt;!-- TODO replace wiki codes --&gt;

'''Future changes'''
* A few gadgets/user scripts which add icons to the Minerva skin need to have their CSS updated. There are more details available including a [[phab:T344067|search for all existing instances and how to update them]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/33|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W33&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 06:00, 15 August 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25428668 --&gt;

== Wikipedia translation of the week: 2023-34 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Insect toxin]]'''&lt;br /&gt; &lt;small&gt;''([[:de:Insektengift]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:PDB 1lmr EBI.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Insect toxins''' are various protein toxins produced by insect species. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:32, 21 August 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25427472 --&gt;

== Tech News: 2023-34 ==

&lt;section begin=&quot;technews-2023-W34&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/34|Translations]] are available.

'''Recent changes'''
* The [https://gdrive-to-commons.toolforge.org/ GDrive to Commons Uploader] tool is now available. It enables [[m:Special:MyLanguage/GDrive to Commons Uploader|securely selecting and uploading files]] from your Google Drive directly to Wikimedia Commons. [https://phabricator.wikimedia.org/T267868]
* From now on, we will announce new Wikimedia wikis in Tech News, so you can update any tools or pages.
** Since the last edition, two new wikis have been created:
*** a Wiktionary in [[d:Q7121294|Pa'O]] ([[wikt:blk:|&lt;code&gt;wikt:blk:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T343540]
*** a Wikisource in [[d:Q34002|Sundanese]] ([[s:su:|&lt;code&gt;s:su:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T343539]
** To catch up, the next most recent six wikis are:
*** Wikifunctions ([[f:|&lt;code&gt;f:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T275945]
*** a Wiktionary in [[d:Q2891049|Mandailing]] ([[wikt:btm:|&lt;code&gt;wikt:btm:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T335216]
*** a Wikipedia in [[d:Q5555465|Ghanaian Pidgin]] ([[w:gpe:|&lt;code&gt;w:gpe:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T335969]
*** a Wikinews in [[d:Q3111668|Gungbe]] ([[n:guw:|&lt;code&gt;n:guw:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T334394]
*** a Wiktionary in [[d:Q33522|Kabardian]] ([[wikt:kbd:|&lt;code&gt;wikt:kbd:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T333266]
*** a Wikipedia in [[d:Q35570|Fante]] ([[w:fat:|&lt;code&gt;w:fat:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T335016]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.23|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-08-22|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-08-23|en}}. It will be on all wikis from {{#time:j xg|2023-08-24|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).

'''Future changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] There is an existing [[mw:Stable interface policy|stable interface policy]] for MediaWiki backend code. There is a [[mw:User:Jdlrobson/Stable interface policy/frontend|proposed stable interface policy for frontend code]]. This is relevant for anyone who works on gadgets or Wikimedia frontend code. You can read it, discuss it, and let the proposer know if there are any problems. [https://phabricator.wikimedia.org/T344079]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/34|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W34&quot;/&gt;

15:25, 21 August 2023 (UTC)
&lt;!-- Message sent by User:Trizek (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25497111 --&gt;

== Wikipedia translation of the week: 2023-35 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Manchester Blitz]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Air Raid Damage in Britain- Manchester HU49833.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Manchester Blitz''' (also known as the Christmas Blitz) was the heavy bombing of the city of Manchester and its surrounding areas in North West England during the Second World War by the German Luftwaffe. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:16, 28 August 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25427472 --&gt;

== Tech News: 2023-35 ==

&lt;section begin=&quot;technews-2023-W35&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/35|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] As part of the changes for the [[m:Community Wishlist Survey 2022/Better diff handling of paragraph splits|better diff handling of paragraph splits]], improved detection of splits is being rolled out. Over the last two weeks, we deployed this support to [[wikitech:Deployments/Train#Groups|group0]] and group1 wikis. This week it will be deployed to group2 wikis. [https://phabricator.wikimedia.org/T341754]
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] All [[{{#special:Contributions}}]] pages now show the user's local edit count and the account's creation date. [https://phabricator.wikimedia.org/T324166]
* Wikisource users can now use the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;prpbengalicurrency&lt;/code&gt;&lt;/bdi&gt; label to denote Bengali currency characters as page numbers inside the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;&lt;pagelist&gt;&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; tag.  [https://phabricator.wikimedia.org/T268932]
* Two preferences have been relocated. The preference &quot;{{int:visualeditor-preference-visualeditor}}&quot; is now shown on the [[Special:Preferences#mw-prefsection-editing|&quot;{{int:prefs-editing}}&quot; tab]] at all wikis. Previously it was shown on the &quot;{{int:prefs-betafeatures}}&quot; tab at some wikis. The preference &quot;{{int:visualeditor-preference-newwikitexteditor-enable}}&quot; is now also shown on the &quot;{{int:prefs-editing}}&quot; tab at all wikis, instead of the &quot;{{int:prefs-betafeatures}}&quot; tab. [https://phabricator.wikimedia.org/T335056][https://phabricator.wikimedia.org/T344158]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.24|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-08-29|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-08-30|en}}. It will be on all wikis from {{#time:j xg|2023-08-31|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] New signups for a Wikimedia developer account will start being pushed towards &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[https://idm.wikimedia.org/ idm.wikimedia.org]&lt;/bdi&gt;, rather than going via Wikitech. [[wikitech:IDM|Further information about the new system is available]].
* All right-to-left language wikis, plus Korean, Armenian, Ukrainian, Russian, and Bulgarian Wikipedias, will have a link in the sidebar that provides a short URL of that page, using the [[m:Special:MyLanguage/Wikimedia URL Shortener|Wikimedia URL Shortener]]. This feature will come to more wikis in future weeks. [https://phabricator.wikimedia.org/T267921]

'''Future changes'''
* The removal of the [[mw:Special:MyLanguage/Extension:DoubleWiki|DoubleWiki extension]] is being discussed. This extension currently allows Wikisource users to view articles from multiple language versions side by side when the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;=&gt;&lt;/code&gt;&lt;/bdi&gt; symbol next to a specific language edition is selected. Comments on this are welcomed at [[phab:T344544|the phabricator task]].
* A proposal has been made to merge the second hidden-categories list (which appears below the wikitext editing form) with the main list of categories (which is further down the page). [[phab:T340606|More information is available on Phabricator]]; feedback is welcome!

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/35|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W35&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 14:00, 28 August 2023 (UTC)
&lt;!-- Message sent by User:Trizek (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25510866 --&gt;

== Wikipedia translation of the week: 2023-36 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Ghana Independence Act 1957]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Ghana Independence Act 1957''' is an Act of the Parliament of the United Kingdom that granted the Gold Coast fully responsible government within the British Commonwealth of Nations under the name of Ghana 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:18, 4 September 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25427472 --&gt;

== Tech News: 2023-36 ==

&lt;section begin=&quot;technews-2023-W36&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/36|Translations]] are available.

'''Recent changes'''
* [[m:Wikisource_EditInSequence|EditInSequence]], a feature that allows users to edit pages faster on Wikisource has been moved to a Beta Feature based on community feedback. To enable it, you can navigate to the [[Special:Preferences#mw-prefsection-betafeatures|beta features tab in Preferences]]. [https://phabricator.wikimedia.org/T308098]
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] As part of the changes for the [[m:Special:MyLanguage/Community Wishlist Survey 2022/Generate Audio for IPA|Generate Audio for IPA]] and [[m:Community Wishlist Survey 2022/Multimedia and Commons/Audio links that play on click|Audio links that play on click]] wishlist proposals, the [[mw:Special:MyLanguage/Help:Extension:Phonos#Inline_audio_player_mode|inline audio player mode]] of [[mw:Extension:Phonos|Phonos]] has been deployed to all projects. [https://phabricator.wikimedia.org/T336763]
* There is a new option for Administrators when they are changing the usergroups for a user, to add the user’s user page to their watchlist. This works both via [[{{#special:UserRights}}]] and via the API. [https://phabricator.wikimedia.org/T272294]
* One new wiki has been created:
** a {{int:project-localized-name-group-wikipedia}} in [[d:Q34318|Talysh]] ([[w:tly:|&lt;code&gt;w:tly:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T345166]
'''Problems'''
* The [[mw:Special:MyLanguage/Extension:LoginNotify|LoginNotify extension]] was not sending notifications since January. It has now been fixed, so going forward, you may see notifications for failed login attempts, and successful login attempts from a new device. [https://phabricator.wikimedia.org/T344785]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.25|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-09-05|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-09-06|en}}. It will be on all wikis from {{#time:j xg|2023-09-07|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* Starting on Wednesday, a new set of Wikipedias will get &quot;[[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]]&quot; ({{int:project-localized-name-mhrwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-miwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-minwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mkwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mlwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mrwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mrjwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mtwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mwlwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-myvwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mznwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nahwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-napwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ndswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nds_nlwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-newiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-newwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-novwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nqowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nrmwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nsowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nvwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nywiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ocwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-olowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-omwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-orwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-oswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pagwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pamwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-papwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pcdwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pdcwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pflwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pihwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pmswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pnbwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pntwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pswiki/en}}). This is part of the [[phab:T304110|progressive deployment of this tool to more Wikipedias]]. The communities can [[mw:Special:MyLanguage/Growth/Community configuration|configure how this feature works locally]]. [https://phabricator.wikimedia.org/T308137][https://phabricator.wikimedia.org/T308138]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/36|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W36&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:34, 4 September 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25566983 --&gt;

== Wikipedia translation of the week: 2023-37 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Betrayal trauma]]'''&lt;br /&gt; &lt;small&gt;''([[:sv:Svektrauma]]) ([[:ar:صدمة الخيانة]]) ([[:ko:배신 트라우마]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Betrayal trauma''' is defined as a trauma perpetrated by someone with whom the victim is close to and reliant upon for support and survival. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:49, 11 September 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25427472 --&gt;

== Tech News: 2023-37 ==

&lt;section begin=&quot;technews-2023-W37&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/37|Translations]] are available.

'''Recent changes'''
* [[mw:Special:MyLanguage/ORES|ORES]], the revision evaluation service, is now using a new open-source infrastructure on all wikis except for English Wikipedia and Wikidata. These two will follow this week. If you notice any unusual results from the Recent Changes filters that are related to ORES (for example, &quot;{{int:ores-rcfilters-damaging-title}}&quot; and &quot;{{int:ores-rcfilters-goodfaith-title}}&quot;), please [[mw:Talk:Machine Learning|report them]]. [https://phabricator.wikimedia.org/T342115]
* When you are logged in on one Wikimedia wiki and visit a different Wikimedia wiki, the system tries to log you in there automatically. This has been unreliable for a long time. You can now visit the login page to make the system try extra hard. If you feel that made logging in better or worse than it used to be, your feedback is appreciated. [https://phabricator.wikimedia.org/T326281]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.26|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-09-12|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-09-13|en}}. It will be on all wikis from {{#time:j xg|2023-09-14|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The [[mw:Special:MyLanguage/Technical decision making|Technical Decision-Making Forum Retrospective]] team invites anyone involved in the technical field of Wikimedia projects to signup to and join [[mw:Technical decision making/Listening Sessions|one of their listening sessions]] on 13 September. Another date will be scheduled later. The goal is to improve the technical decision-making processes.
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] As part of the changes for the [[m:Special:MyLanguage/Community Wishlist Survey 2022/Better diff handling of paragraph splits|Better diff handling of paragraph splits]] wishlist proposal, the inline switch widget in diff pages is being rolled out this week to all wikis. The inline switch will allow viewers to toggle between a unified inline or two-column diff wikitext format. [https://phabricator.wikimedia.org/T336716]

'''Future changes'''
* All wikis will be read-only for a few minutes on 20 September. [[m:Special:MyLanguage/Tech/Server switch|This is planned at 14:00 UTC.]] More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [https://phabricator.wikimedia.org/T345263]
* The Enterprise API is launching a new feature called &quot;[http://breakingnews-beta.enterprise.wikimedia.com/ breaking news]&quot;. Currently in BETA, this attempts to identify likely &quot;newsworthy&quot; topics as they are currently being written about in any Wikipedia. Your help is requested to improve the accuracy of its detection model, especially on smaller language editions, by recommending templates or identifiable editing patterns. See more information at [[mw:Special:MyLanguage/Wikimedia Enterprise/Breaking news|the documentation page]] on MediaWiki or [[m:Special:MyLanguage/Wikimedia Enterprise/FAQ#What is Breaking News|the FAQ]] on Meta.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/37|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W37&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:08, 11 September 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25589064 --&gt;

== Wikipedia translation of the week: 2023-38 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:es:Genocidio del Putumayo]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Putumayo genocide]]) ([[:ca:Genocidi del Putumayo]])''&lt;/small&gt;&lt;/div&gt;

Please be bold and help translate this article!

----
[[File:The Putumayo - the devil's paradise, travels in the Peruvian Amazon Region and an account of the atrocities committed upon the Indians therein (1913) (14782203995).jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Putumayo genocide''' is the term which is used in reference to the enslavement, massacres and ethnocide of the indigenous population of the Amazon at the hands of the Peruvian Amazon Company, specifically in the area between the Putumayo River and the Caquetá River during the Amazon rubber boom period from 1879 to 1912. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 03:38, 18 September 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25599361 --&gt;

== Tech News: 2023-38 ==

&lt;section begin=&quot;technews-2023-W38&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/38|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] MediaWiki now has a [[mw:Stable interface policy/frontend|stable interface policy for frontend code]] that more clearly defines how we deprecate MediaWiki code and wiki-based code (e.g. gadgets and user scripts). Thank you to everyone who contributed to the content and discussions. [https://phabricator.wikimedia.org/T346467][https://phabricator.wikimedia.org/T344079]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.27|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-09-19|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-09-20|en}}. It will be on all wikis from {{#time:j xg|2023-09-21|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* All wikis will be read-only for a few minutes on September 20. [[m:Special:MyLanguage/Tech/Server switch|This is planned at 14:00 UTC.]] [https://phabricator.wikimedia.org/T345263]
* All wikis will have a link in the sidebar that provides a short URL of that page, using the [[m:Special:MyLanguage/Wikimedia URL Shortener|Wikimedia URL Shortener]]. [https://phabricator.wikimedia.org/T267921]

'''Future changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The team investigating the Graph Extension posted [[mw:Extension:Graph/Plans#Proposal|a proposal for reenabling it]] and they need your input.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/38|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W38&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:20, 18 September 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25623533 --&gt;

== Tech News: 2023-39 ==

&lt;section begin=&quot;technews-2023-W39&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/39|Translations]] are available.

'''Recent changes'''
* The Vector 2022 skin will now remember the pinned/unpinned status for the Table of Contents for all logged-out users. [https://phabricator.wikimedia.org/T316060]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.28|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-09-26|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-09-27|en}}. It will be on all wikis from {{#time:j xg|2023-09-28|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The ResourceLoader &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;mediawiki.ui&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; modules are now deprecated as part of the move to Vue.js and Codex. There is a [[mw:Codex/Migrating_from_MediaWiki_UI|guide for migrating from MediaWiki UI to Codex]] for any tools that use it. More [[phab:T346468|details are available in the task]] and your questions are welcome there.
* Gadget definitions will have a [[mw:Special:MyLanguage/Extension:Gadgets#Options|new &quot;namespaces&quot; option]]. The option takes a list of namespace IDs. Gadgets that use this option will only load on pages in the given namespaces.

'''Future changes'''
* New variables will be added to [[mw:Special:MyLanguage/Extension:AbuseFilter|AbuseFilter]]: &lt;code&gt;&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;global_account_groups&lt;/bdi&gt;&lt;/code&gt; and &lt;code&gt;&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;global_account_editcount&lt;/bdi&gt;&lt;/code&gt;. They are available only when an account is being created. You can use them to prevent blocking automatic creation of accounts when users with many edits elsewhere visit your wiki for the first time. [https://phabricator.wikimedia.org/T345632][https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:AbuseFilter/Rules_format]

'''Meetings'''
* You can join the next meeting with the Wikipedia mobile apps teams. During the meeting, we will discuss the current features and future roadmap. The meeting will be on [https://zonestamp.toolforge.org/1698426015 27 October at 17:00 (UTC)]. See [[mw:Special:MyLanguage/Wikimedia_Apps/Office_Hours#October_2023|details and how to join]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/39|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W39&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 16:51, 26 September 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25655264 --&gt;

== Tech News: 2023-40 ==

&lt;section begin=&quot;technews-2023-W40&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/40|Translations]] are available.

'''Recent changes'''
* There is a new [[Special:Preferences#mw-prefsection-rendering-advancedrendering|user preference]] for &quot;{{int:tog-forcesafemode}}&quot;. This setting will make pages load without including any on-wiki JavaScript or on-wiki stylesheet pages. It can be useful for debugging broken JavaScript gadgets. [https://phabricator.wikimedia.org/T342347]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Gadget definitions now have a [[mw:Special:MyLanguage/Extension:Gadgets#Options|new &quot;&lt;var&gt;contentModels&lt;/var&gt;&quot; option]]. The option takes a list of page content models, like &lt;code&gt;&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;wikitext&lt;/bdi&gt;&lt;/code&gt; or &lt;code&gt;&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;css&lt;/bdi&gt;&lt;/code&gt;. Gadgets that use this option will only load on pages with the given content models.

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.29|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-10-03|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-10-04|en}}. It will be on all wikis from {{#time:j xg|2023-10-05|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).

'''Future changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The Vector 2022 skin will no longer use the custom styles and scripts of Vector legacy (2010). The change will be made later this year or in early 2024. See [[mw:Special:MyLanguage/Reading/Web/Desktop Improvements/Features/Loading Vector 2010 scripts|how to adjust the CSS and JS pages on your wiki]]. [https://phabricator.wikimedia.org/T331679]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/40|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W40&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:27, 3 October 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25686930 --&gt;

== Tech News: 2023-41 ==

&lt;section begin=&quot;technews-2023-W41&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/41|Translations]] are available.

'''Recent changes'''
* One new wiki has been created: a {{int:project-localized-name-group-wikipedia}} in [[d:Q33291|Fon]] ([[w:fon:|&lt;code&gt;w:fon:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T347935]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.41/wmf.30|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-10-10|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-10-11|en}}. It will be on all wikis from {{#time:j xg|2023-10-12|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).
* Starting on Wednesday, a new set of Wikipedias will get &quot;[[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]]&quot; ({{int:project-localized-name-swwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-wawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-warwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-wowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-xalwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-xhwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-xmfwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-yiwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-yowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-zawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-zeawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-zh_min_nanwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-zuwiki/en}}). This is part of the [[phab:T304110|progressive deployment of this tool to more Wikipedias]]. The communities can [[mw:Special:MyLanguage/Growth/Community configuration|configure how this feature works locally]]. [https://phabricator.wikimedia.org/T308139]
* At some wikis, newcomers are suggested images from Commons to add to articles without any images. Starting on Tuesday, newcomers at these wikis will be able to add images to unillustrated article sections. The specific wikis are listed under &quot;Images recommendations&quot; [[mw:Special:MyLanguage/Growth/Deployment table|at the Growth team deployment table]]. You can [[mw:Special:MyLanguage/Help:Growth/Tools/Add an image|learn more about this feature.]] [https://phabricator.wikimedia.org/T345940]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] In the mobile web skin (Minerva) the CSS ID &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;#page-actions&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; will be replaced with &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;#p-views&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;. This change is to make it consistent with other skins and to improve support for gadgets and extensions in the mobile skin. A few gadgets may need to be updated; there are [https://phabricator.wikimedia.org/T348267 details and search-links in the task].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/41|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W41&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 14:39, 9 October 2023 (UTC)
&lt;!-- Message sent by User:Trizek (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25712895 --&gt;

== Wikipedia translation of the week: 2023-42 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Athyma nefte]]'''&lt;br /&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:VB 019 Color Sergeant UP.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''Athyma nefte''''', the colour sergeant, is a species of brush-footed butterfly found in tropical South and Southeast Asia. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:58, 16 October 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25693965 --&gt;

== Tech News: 2023-42 ==

&lt;section begin=&quot;technews-2023-W42&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/42|Translations]] are available.

'''Recent changes'''
* The [[m:Special:MyLanguage/Help:Unified login|Unified login]] system's edge login should now be fixed for some browsers (Chrome, Edge, Opera). This means that if you visit a new sister project wiki, you should be logged in automatically without the need to click &quot;Log in&quot; or reload the page. Feedback on whether it's working for you is welcome. [https://phabricator.wikimedia.org/T347889]
* [[mw:Special:MyLanguage/Manual:Interface/Edit_notice|Edit notices]] are now available within the MobileFrontend/Minerva skin. This feature was inspired by [[w:en:Wikipedia:EditNoticesOnMobile|the gadget on English Wikipedia]]. See more details in [[phab:T316178|T316178]].

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.1|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-10-17|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-10-18|en}}. It will be on all wikis from {{#time:j xg|2023-10-19|en}} ([[mw:MediaWiki 1.41/Roadmap|calendar]]).

'''Future changes'''
* In 3 weeks, in the Vector 2022 skin, code related to &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;addPortletLink&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;#p-namespaces&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; that was deprecated one year ago will be removed. If you notice tools that should appear next to the &quot;Discussion&quot; tab are then missing, please tell the gadget's maintainers to see [[phab:T347907|instructions in the Phabricator task]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/42|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W42&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:47, 16 October 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25745824 --&gt;

== Wikipedia translation of the week: 2023-43 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Typhoon Rusa]]'''&lt;br /&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Rusa 2002-08-27 0350Z.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Typhoon Rusa''' was the most powerful typhoon to strike South Korea in 43 years. It was the 21st JTWC tropical depression, the 15th named storm, and the 10th typhoon of the 2002 Pacific typhoon season. It developed on August 22 from the monsoon trough in the northwestern Pacific Ocean, well to the southeast of Japan. For several days, Rusa moved to the northwest, eventually intensifying into a powerful typhoon. On August 26, the storm moved across the Amami Islands of Japan, where Rusa left 20,000 people without power and caused two fatalities. Across Japan, the typhoon dropped torrential rainfall peaking at 902 mm (35.5 in) in Tokushima Prefecture. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:50, 23 October 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25693965 --&gt;

== Tech News: 2023-43 ==

&lt;section begin=&quot;technews-2023-W43&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/43|Translations]] are available.

'''Recent changes'''
* There is a new [[mw:Special:MyLanguage/Wikimedia Language engineering/Newsletter/2023/October|Language and internationalization newsletter]], written quarterly. It contains updates on new feature development, improvements in various language-related technical projects, and related support work.
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Source map support has been enabled on all wikis. When you open the debugger in your browser's developer tools, you should be able to see the unminified JavaScript source code. [https://phabricator.wikimedia.org/T47514]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.2|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-10-24|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-10-25|en}}. It will be on all wikis from {{#time:j xg|2023-10-26|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]).

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/43|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W43&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:17, 23 October 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25782286 --&gt;

== Wikipedia translation of the week: 2023-44 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Hein Eersel]]'''&lt;br /&gt; &lt;small&gt;''([[:nl:Hein Eersel]]) ([[:it:Hein Eersel]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:HeinEersel.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Christiaan Hendrik &quot;Hein&quot; Eersel''' was a Surinamese linguist and cultural researcher. He served as Minister of Education and Population Development in the cabinet of acting Prime Minister Arthur Johan May. He was also the first chancellor of the University of Suriname. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:09, 30 October 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25797248 --&gt;

== Tech News: 2023-44 ==

&lt;section begin=&quot;technews-2023-W44&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/44|Translations]] are available.

'''Recent changes'''
* The Structured Content team, as part of its project of [[:commons:Commons:WMF support for Commons/Upload Wizard Improvements|improving UploadWizard on Commons]], made some UX improvements to the upload step of choosing own vs not own work ([[phab:T347590|T347590]]), as well as to the licensing step for own work ([[phab:T347756|T347756]]).
* The Design Systems team has released version 1.0.0 of [[wmdoc:codex/latest/|Codex]], the new design system for Wikimedia. See the [[mw:Special:MyLanguage/Design_Systems_Team/Announcing_Codex_1.0|full announcement about the release of Codex 1.0.0]].

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.3|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-10-31|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-11-01|en}}. It will be on all wikis from {{#time:j xg|2023-11-02|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]).
* Listings on category pages are sorted on each wiki for that language using a [[:w:en:International Components for Unicode|library]]. For a brief period on 2 November, changes to categories will not be sorted correctly for many languages. This is because the developers are upgrading to a new version of the library. They will then use a script to fix the existing categories. This will take a few hours or a few days depending on how big the wiki is. You can [[mw:Special:MyLanguage/Wikimedia Technical Operations/ICU announcement|read more]]. [https://phabricator.wikimedia.org/T345561][https://phabricator.wikimedia.org/T267145] 
* Starting November 1, the impact module (Special:Impact) will be upgraded by the Growth team. The new impact module shows newcomers more data regarding their impact on the wiki. It was tested by a few wikis during the last few months. [https://phabricator.wikimedia.org/T336203]

'''Future changes'''
* There is [[mw:Special:MyLanguage/Extension:Graph/Plans#Roadmap|a proposed plan]] for re-enabling the Graph Extension. You can help by reviewing this proposal and [[mw:Extension_talk:Graph/Plans#c-PPelberg_(WMF)-20231020221600-Update:_20_October|sharing what you think about it]].
* The WMF is working on making it possible for administrators to [[mw:Special:MyLanguage/Community_configuration_2.0|edit MediaWiki configuration directly]]. This is similar to previous work on Special:EditGrowthConfig. [[phab:T349757|A technical RfC is running until November 08, where you can provide feedback.]] 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/44|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W44&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:21, 30 October 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25801989 --&gt;

== Tech News: 2023-45 ==

&lt;section begin=&quot;technews-2023-W45&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/45|Translations]] are available.

'''Recent changes'''
* In the Vector 2022 skin, the default font-size of a number of navigational elements (tagline, tools menu, navigational links, and more) has been increased slightly to match the font size used in page content. [https://phabricator.wikimedia.org/T346062]

'''Problems'''
* Last week, there was a problem displaying some recent edits on [https://noc.wikimedia.org/conf/highlight.php?file=dblists/s5.dblist a few wikis], for 1-6 hours. The edits were saved but not immediately shown. This was due to a database problem. [https://phabricator.wikimedia.org/T350443]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.4|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-11-07|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-11-08|en}}. It will be on all wikis from {{#time:j xg|2023-11-09|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]).
* The Growth team will reassign newcomers from former mentors to [[mw:Special:MyLanguage/Growth/Structured mentor list|the currently active mentors]]. They have also changed the notification language to be more user-friendly. [https://phabricator.wikimedia.org/T330071][https://phabricator.wikimedia.org/T327493]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/45|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W45&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:06, 6 November 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25838105 --&gt;

== Wikipedia translation of the week: 2023-45 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Reclaim the Night]]'''&lt;br /&gt; &lt;small&gt;''([[:de:Reclaim the Night]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Reclaim the Night 2014.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Reclaim the Night''' is a movement started in Leeds in 1977 as part of the Women's Liberation Movement. Marches demanding that women be able to move throughout public spaces at night took place across England until the 1990s. Later, the organisation was revived and sponsors annual and national marches against rape and violence against women. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 00:40, 8 November 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25797248 --&gt;

== Wikipedia translation of the week: 2023-46 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Ishe Komborera Africa]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Ishe Komborera Africa.mp3|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
&quot;'''Ishe Komborera Africa'''&quot; (Shona for: God Bless Africa), also called &quot;Ishe Komborera Zimbabwe&quot; (Shona for: God Bless Zimbabwe), was the Zimbabwean national anthem from 1980 to 1994. It was the country's first national anthem after gaining independence in 1980. It is a translation of 19th-century South African schoolteacher Enoch Sontonga's popular African hymn &quot;Nkosi Sikelel' iAfrika&quot; into Zimbabwe's native Shona and Ndebele languages. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 00:38, 13 November 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25797248 --&gt;

== Tech News: 2023-46 ==

&lt;section begin=&quot;technews-2023-W46&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/46|Translations]] are available.

'''Recent changes'''
* Four new wikis have been created:
** a Wikipedia in [[d:Q7598268|Moroccan Amazigh]] ([[w:zgh:|&lt;code&gt;w:zgh:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T350216]
** a Wikipedia in [[d:Q35159|Dagaare]] ([[w:dga:|&lt;code&gt;w:dga:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T350218]
** a Wikipedia in [[d:Q33017|Toba Batak]] ([[w:bbc:|&lt;code&gt;w:bbc:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T350320]
** a Wikiquote in [[d:Q33151|Banjar]] ([[q:bjn:|&lt;code&gt;q:bjn:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T350217]

'''Problems'''
* Last week, users who previously visited Meta-Wiki or Wikimedia Commons and then became logged out on those wikis could not log in again. The problem is now resolved. [https://phabricator.wikimedia.org/T350695]
* Last week, some pop-up dialogs and menus were shown with the wrong font size. The problem is now resolved. [https://phabricator.wikimedia.org/T350544]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.5|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-11-14|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-11-15|en}}. It will be on all wikis from {{#time:j xg|2023-11-16|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]).

'''Future changes'''
* Reference Previews are coming to many wikis as a default feature. They are popups for references, similar to the [[mw:Special:MyLanguage/Page Previews|PagePreviews feature]]. [[m:WMDE Technical Wishes/ReferencePreviews#Opt-out feature|You can opt out]] of seeing them. If you are [[Special:Preferences#mw-prefsection-gadgets|using the gadgets]] Reference Tooltips or Navigation Popups, you won’t see Reference Previews. [[phab:T282999|Deployment]] is planned for November 22, 2023. 
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Canary (also known as heartbeat) events will be produced into [https://stream.wikimedia.org/?doc#/streams Wikimedia event streams] from December 11. Streams users are advised to filter out these events, by discarding all events where &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;meta.domain == &quot;canary&quot;&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;. Updates to [[mw:Special:MyLanguage/Manual:Pywikibot|Pywikibot]] or [https://github.com/ChlodAlejandro/wikimedia-streams wikimedia-streams] will discard these events by default. [https://phabricator.wikimedia.org/T266798]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/46|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W46&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:52, 13 November 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25859263 --&gt;

== Wikipedia translation of the week: 2023-47 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Bhagavata Mela]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Bhagavata Mela''' is a classical Indian dance that is performed in Tamil Nadu, particularly the Thanjavur area. It is choreographed as an annual Vaishnavism tradition in Melattur and nearby regions, and celebrated as a dance-drama performance art. The dance art has roots in a historic migration of practitioners of Kuchipudi, another Indian classical dance art, from Andhra Pradesh to the kingdom of Tanjavur.

The term Bhagavata, state Brandon and Banham, refers to the Hindu text Bhagavata Purana. Mela is a Sanskrit word that means &quot;gathering, meeting of a group&quot; and connotes a folk festival. The traditional Bhagavata Mela performance acts out the legends of Hinduism, set to the Carnatic style music. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 00:38, 04:07, 20 November 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25797248 --&gt;

== Tech News: 2023-47 ==

&lt;section begin=&quot;technews-2023-W47&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/47|Translations]] are available.

'''Changes later this week'''
* There is no new MediaWiki version this week. [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* Starting on Wednesday, a new set of Wikipedias will get &quot;[[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]]&quot; ({{int:project-localized-name-quwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-rmwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-rmywiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-rnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-roa_rupwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-roa_tarawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ruewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-rwwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-sawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-sahwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-satwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-scwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-scnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-scowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-sdwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-sewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-sgwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-shwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-siwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-skwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-slwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-smwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-sowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-sqwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-srwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-srnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-sswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-stwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-stqwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-suwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-szlwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tcywiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tetwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tgwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-thwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tkwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tlwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-towiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tpiwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-trwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ttwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-twwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tywiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tyvwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-udmwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ugwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-uzwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-vewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-vecwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-vepwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-vlswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-vowiki/en}}). This is part of the [[phab:T304110|progressive deployment of this tool to more Wikipedias]]. The communities can [[mw:Special:MyLanguage/Growth/Community configuration|configure how this feature works locally]]. [https://phabricator.wikimedia.org/T308141][https://phabricator.wikimedia.org/T308142][https://phabricator.wikimedia.org/T308143] 
* The Vector 2022 skin will have some minor visual changes to drop-down menus, column widths, and more. These changes were added to four Wikipedias last week. If no issues are found, these changes will proceed to all wikis this week. These changes will make it possible to add new menus for readability and dark mode. [[mw:Special:MyLanguage/Reading/Web/Desktop_Improvements/Updates#November_2023:_Visual_changes,_more_deployments,_and_shifting_focus|Learn more]]. [https://phabricator.wikimedia.org/T347711]

'''Future changes'''
* There is [[mw:Extension talk:Graph/Plans#Update: 15 November|an update on re-enabling the Graph Extension]]. To speed up the process, Vega 2 will not be supported and only [https://phabricator.wikimedia.org/T335325 some protocols] will be available at launch. You can help by sharing what you think about the plan.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/47|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W47&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:55, 21 November 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25884616 --&gt;

== Wikipedia translation of the week: 2023-48 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:fr:Zanskari]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Zaniskari]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Zaniskari Horse in Ladakh, India.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Zaniskari''' or '''Zanskari''' is a breed of small mountain horse or pony from Ladakh, in northern India. It is named for the Zanskar valley or region in Kargil district. It is similar to the Spiti breed of Himachal Pradesh, but is better adapted to work at high altitude. Like the Spiti, it shows similarities to the Tibetan breeds of neighbouring Tibet. It is of medium size, and is often grey in colour. The breed is considered endangered, as there are only a few hundred alive today, and a conservation programme has been started at Padum, Zanskar, in the Kargil district of Ladakh. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:44, 27 November 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25797248 --&gt;

== Tech News: 2023-48 ==

&lt;section begin=&quot;technews-2023-W48&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/48|Translations]] are available.

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.7|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-11-28|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-11-29|en}}. It will be on all wikis from {{#time:j xg|2023-11-30|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). There is no new MediaWiki version next week. [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] MediaWiki's JavaScript system will now allow &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;async&lt;/code&gt;/&lt;code&gt;await&lt;/code&gt;&lt;/bdi&gt; syntax in gadgets and user scripts. Gadget authors should remember that users' browsers may not support it, so it should be used appropriately. [https://phabricator.wikimedia.org/T343499]
* The deployment of &quot;[[mw:Special:MyLanguage/Help:Growth/Tools/Add_a_link|Add a link]]&quot; announced [[m:Special:MyLanguage/Tech/News/2023/47|last week]] was postponed. It will resume this week.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/48|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W48&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:09, 27 November 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25906379 --&gt;

== Wikipedia translation of the week: 2023-49 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Sheikh Hussein]]'''&lt;br /&gt; &lt;small&gt;''([[:fr:Sheikh Hussein]]) ([[:it:Scec Hussèn]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Sheikh Hussein.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Sheikh Hussein''' is a town in south-eastern Ethiopia. The site has been recorded in the tentative list for UNESCO World Heritage List since 2011 as a religious, cultural and historical site. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:34, 4 December 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25921616 --&gt;

== Tech News: 2023-49 ==

&lt;section begin=&quot;technews-2023-W49&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/49|Translations]] are available.

'''Recent changes'''
* The spacing between paragraphs on Vector 2022 has been changed from 7px to 14px to match the size of the text. This will make it easier to distinguish paragraphs from sentences. [https://phabricator.wikimedia.org/T351754]
* The &quot;{{int:Visualeditor-dialog-meta-categories-defaultsort-label}}&quot; feature in VisualEditor is working again. You no longer need to switch to source editing to edit &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;{{DEFAULTSORT:...}}&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; keywords. [https://phabricator.wikimedia.org/T337398]

'''Changes later this week'''
* There is no new MediaWiki version this week. [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* On 6 December, people who have the enabled the preference for &quot;{{int:Discussiontools-preference-visualenhancements}}&quot; will notice the [[mw:Special:MyLanguage/Talk pages project/Usability|talk page usability improvements]] appear on pages that include the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;__NEWSECTIONLINK__&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; magic word. If you notice any issues, please [[phab:T352232|share them with the team on Phabricator]].

'''Future changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The Toolforge [[wikitech:News/Toolforge Grid Engine deprecation|Grid Engine shutdown process]] will start on December 14. Maintainers of [[toolforge:grid-deprecation|tools that still use this old system]] should plan to migrate to Kubernetes, or tell the team your plans on Phabricator in the task about your tool, before that date. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/VIWWQKMSQO2ED3TVUR7KPPWRTOBYBVOA/]
* Communities using [[mw:Special:MyLanguage/Structured_Discussions|Structured Discussions]] are being contacted regarding [[mw:Special:MyLanguage/Structured_Discussions/Deprecation|the upcoming deprecation of Structured Discussions]]. You can read more about this project, and share your comments, [[mw:Special:MyLanguage/Structured_Discussions/Deprecation|on the project's page]].

'''Events'''
* Registration &amp; Scholarship applications are now open for the [[mw:Special:MyLanguage/Wikimedia Hackathon 2024|Wikimedia Hackathon 2024]] that will take place from 3–5 May in Tallinn, Estonia. Scholarship applications are open until 5 January 2024.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/49|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W49&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:50, 4 December 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25914435 --&gt;

== Wikipedia translation of the week: 2023-50 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:fr:Applaudissements aux fenêtres pendant la pandémie de Covid-19]]'''&lt;br /&gt; &lt;small&gt;''([[:es:Aplauso por los trabajadores de la salud]]) ([[:gl:Aplauso ao persoal sanitario]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Koronabirus konfinamendua Lasarten 2020-03-29.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
During the COVID-19 pandemic, applauding daily at a scheduled hour was a gesture of acclamation, recognition and gratitude towards health professionals in tribute to their work at the time. This habit emerged in January 2020 in Wuhan, where the pandemic originated, and then spread to several cities around the world during the quarantines and sanitary cordons ordered as preventive measures, Italy being the first one. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:26, 11 December 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25925561 --&gt;

== Tech News: 2023-50 ==

&lt;section begin=&quot;technews-2023-W50&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/50|Translations]] are available.

'''Recent changes'''
* On Wikimedia Commons, there are some minor user-interface improvements for the &quot;choosing own vs not own work&quot; step in the UploadWizard. This is part of the Structured Content team's project of [[:commons:Commons:WMF support for Commons/Upload Wizard Improvements|improving UploadWizard on Commons]]. [https://phabricator.wikimedia.org/T352707][https://phabricator.wikimedia.org/T352709]

'''Problems'''
* There was a problem showing the [[mw:Special:MyLanguage/Growth/Personalized first day/Newcomer homepage|Newcomer homepage]] feature with the &quot;impact module&quot; and their page-view graphs, for a few days in early December. This has now been fixed. [https://phabricator.wikimedia.org/T352352][https://phabricator.wikimedia.org/T352349]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.9|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-12-12|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-12-13|en}}. It will be on all wikis from {{#time:j xg|2023-12-14|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''Future changes'''
* [[File:Octicons-tools.svg|15px|link=]] The [https://wikimediafoundation.limesurvey.net/796964 2023 Developer Satisfaction Survey] is seeking the opinions of the Wikimedia developer community. Please take the survey if you have any role in developing software for the Wikimedia ecosystem. The survey is open until 5 January 2024, and has an associated [[foundation:Legal:December_2023_Developer_Satisfaction_Survey|privacy statement]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/50|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W50&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 02:13, 12 December 2023 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25945501 --&gt;

== Wikipedia translation of the week: 2023-51 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Jamaica Bay Wildlife Refuge]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Aerial view of Subway Island, July 2019.JPG|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Jamaica Bay Wildlife Refuge''' is a wildlife refuge in New York City managed by the National Park Service as part of Gateway National Recreation Area. It is composed of the open water and intertidal salt marshes of Jamaica Bay. It lies entirely within the boundaries of New York City, divided between the boroughs of Brooklyn to the west and Queens to the east. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:05, 18 December 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25951007 --&gt;

== Tech News: 2023-51 ==

&lt;section begin=&quot;technews-2023-W51&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2023/51|Translations]] are available.

'''Tech News'''
* The next issue of Tech News will be sent out on 8 January 2024 because of [[w:en:Christmas and holiday season|the holidays]].

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.10|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2023-12-19|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2023-12-20|en}}. It will be on all wikis from {{#time:j xg|2023-12-21|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). There is no new MediaWiki version next week. [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* Starting December 18, it won't be possible to activate Structured Discussions on a user's own talk page using the Beta feature. The Beta feature option remains available for users who want to deactivate Structured Discussions. This is part of [[mw:Structured Discussions/Deprecation|Structured Discussions' deprecation work]]. [https://phabricator.wikimedia.org/T248309] 
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] There will be full support for redirects in the Module namespace. The &quot;Move Page&quot; feature will leave an appropriate redirect behind, and such redirects will be appropriately recognized by the software (e.g. hidden from [[{{#special:UnconnectedPages}}]]). There will also be support for [[mw:Special:MyLanguage/Extension:Scribunto/Lua reference manual#Renaming or moving modules|manual redirects]]. [https://phabricator.wikimedia.org/T120794]

'''Future changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The MediaWiki JavaScript documentation is moving to a new format. During the move, you can read the old docs using [https://doc.wikimedia.org/mediawiki-core/REL1_41/js/ version 1.41]. Feedback about [https://doc.wikimedia.org/mediawiki-core/master/js/ the new site] is welcome on the [[mw:Talk:JSDoc_WMF_theme|project talk page]].
* The Wishathon is a new initiative that encourages collaboration across the Wikimedia community to develop solutions for wishes collected through the [[m:Special:MyLanguage/Community Wishlist Survey|Community Wishlist Survey]]. The first community Wishathon will take place from 15–17 March. If you are interested in a project proposal as a user, developer, designer, or product lead, you can [[m:Special:MyLanguage/Event:WishathonMarch2024|register for the event and read more]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2023/51|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2023-W51&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 16:18, 18 December 2023 (UTC)
&lt;!-- Message sent by User:Johan (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=25959059 --&gt;

== Wikipedia translation of the week: 2023-52 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2023 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Plant blindness]]'''&lt;br /&gt; &lt;small&gt;''([[:fr:Cécité botanique]]) ([[:de:Pflanzenblindheit]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Plant blindness 0323.png|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Plant blindness''' is an informally-proposed form of cognitive bias, which in its broadest meaning, is a human tendency to ignore plant species. This includes such phenomena as not noticing plants in the surrounding environment, not recognizing the importance of plant life to the whole biosphere and to human affairs, a philosophical view of plants as an inferior form of life to animals and/or the inability to appreciate the unique features or aesthetics of plants. Related terms include plant‐neglect, zoo-centrism, and zoo‐chauvinism. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:58, 25 December 2023 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=25971304 --&gt;

== Wikipedia translation of the week: 2024-02 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Pax airship disaster]]'''&lt;br /&gt; &lt;small&gt;''([[:pt:Catástrofe do dirigível Pax]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Sim new-mcclures-magazine 1902-09 19 5 (page 75 crop).jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''Pax''''' '''airship disaster''' was the explosion of the ''Pax'' airship on May 12, 1902, in Paris, which killed the Brazilian inventor Augusto Severo and the French mechanic Georges Saché.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 12:14, 8 January 2024 (UTC)''
&lt;/div&gt;
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26033876 --&gt;

== Tech News: 2024-02 ==

&lt;section begin=&quot;technews-2024-W02&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/02|Translations]] are available.

'''Recent changes'''
* [https://mediawiki2latex.wmflabs.org/ mediawiki2latex] is a tool that converts wiki content into the formats of LaTeX, PDF, ODT, and EPUB. The code now runs many times faster due to recent improvements. There is also an optional Docker container you can [[b:de:Benutzer:Dirk_Hünniger/wb2pdf/install#Using_Docker|install]] on your local machine.
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The way that Random pages are selected has been updated. This will slowly reduce the problem of some pages having a lower chance of appearing. [https://phabricator.wikimedia.org/T309477]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.13|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-01-09|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-01-10|en}}. It will be on all wikis from {{#time:j xg|2024-01-11|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/02|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W02&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:20, 9 January 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26026251 --&gt;

== Wikipedia translation of the week: 2024-03 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Conversion to Islam]]'''&lt;br /&gt; &lt;small&gt;''([[:fr:Conversion à l'islam]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Sahadah-Topkapi-Palace.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Conversion to Islam''' is accepting Islam as a religion or faith and rejecting any other religion or irreligion. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:11, 15 January 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26044632 --&gt;

== Tech News: 2024-03 ==

&lt;section begin=&quot;technews-2024-W03&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/03|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Pages that use the JSON [[mw:Special:MyLanguage/Manual:ContentHandler|contentmodel]] will now use tabs instead of spaces for auto-indentation. This will significantly reduce the page size. [https://phabricator.wikimedia.org/T326065]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] [[mw:Special:MyLanguage/Extension:Gadgets|Gadgets]] and personal user scripts may now use JavaScript syntax introduced in ES6 (also known as &quot;ES2015&quot;) and ES7 (&quot;ES2016&quot;). MediaWiki validates the source code to protect other site functionality from syntax errors, and to ensure scripts are valid in all [[mw:Special:MyLanguage/Compatibility#Browsers|supported browsers]]. Previously, Gadgets could use the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;requiresES6&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; option. This option is no longer needed and will be removed in the future. [https://phabricator.wikimedia.org/T75714]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] [[mw:Special:MyLanguage/Manual:Bot passwords|Bot passwords]] and [[mw:Special:MyLanguage/OAuth/Owner-only consumers|owner-only OAuth consumers]] can now be restricted to allow editing only specific pages. [https://phabricator.wikimedia.org/T349957]
* You can now [[mw:Special:MyLanguage/Extension:Thanks|thank]] edits made by bots. [https://phabricator.wikimedia.org/T341388]
* An update on the status of the Community Wishlist Survey for 2024 [[m:Special:MyLanguage/Community Wishlist Survey/Future Of The Wishlist/January 4, 2024 Update|has been published]]. Please read and give your feedback.

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.14|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-01-16|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-01-17|en}}. It will be on all wikis from {{#time:j xg|2024-01-18|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* Starting on January 17, it will not be possible to login to Wikimedia wikis from some specific old versions of the Chrome browser (versions 51–66, released between 2016 and 2018). Additionally, users of iOS 12, or Safari on Mac OS 10.14, may need to login to each wiki separately. [https://phabricator.wikimedia.org/T344791]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;jquery.cookie&lt;/code&gt;&lt;/bdi&gt; module was deprecated and replaced with the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;mediawiki.cookie&lt;/code&gt;&lt;/bdi&gt; module last year. A script has now been run to replace any remaining uses, and this week the temporary alias will be removed. [https://phabricator.wikimedia.org/T354966]

'''Future changes'''
* Wikimedia Deutschland is working to [[m:WMDE Technical Wishes/Reusing references|make reusing references easier]]. They are looking for people who are interested in participating in [https://wikimedia.sslsurvey.de/User-research-into-Reusing-References-Sign-up-Form-2024/en/ individual video calls for user research in January and February].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/03|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W03&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:13, 16 January 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26074460 --&gt;

== Wikipedia translation of the week: 2024-04 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Kinder der Landstrasse]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Kinderdlandstrasse plakat.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Kinder der Landstrasse''' (literally: Children of the Country Road) was a project implemented by the Swiss foundation Pro Juventute from 1926 to 1973. The project aimed to assimilate the itinerant Yenish people in Switzerland by forcibly removing their children from their parents and placing them in orphanages or foster homes. Approximately 590 children were affected by this program. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 02:02, 22 January 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26044632 --&gt;

== Tech News: 2024-04 ==

&lt;section begin=&quot;technews-2024-W04&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/04|Translations]] are available.

'''Problems'''
* A bug in UploadWizard prevented linking to the userpage of the uploader when uploading. It has now been fixed. [https://phabricator.wikimedia.org/T354529]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.15|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-01-23|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-01-24|en}}. It will be on all wikis from {{#time:j xg|2024-01-25|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/04|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W04&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:04, 23 January 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26096197 --&gt;

== Wikipedia translation of the week: 2024-05 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Qurm Nature Reserve]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Al-Qurm Wetlands.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Qurm Nature Reserve''' is a national nature reserve in Muscat Governorate, Oman. Located on the Gulf of Oman coast, the reserve protects a mangrove forest and the surrounding wetland in a small estuary within the urban area of Qurm. Established in 1975, the reserve has been designated as an Important Bird Area since 1994, and as a protected Ramsar site since 2013. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:03, 29 January 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26149847 --&gt;

== Tech News: 2024-05 ==

&lt;section begin=&quot;technews-2024-W05&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/05|Translations]] are available.

'''Recent changes'''
* Starting Monday January 29, all talk pages messages' timestamps will become a link. This link is a permanent link to the comment. It allows users to find the comment they are looking for, even if this comment was moved elsewhere. This will affect all wikis except for the English Wikipedia. You can read more about this change [https://diff.wikimedia.org/2024/01/29/talk-page-permalinks-dont-lose-your-threads/ on Diff] or [[mw:Special:MyLanguage/Help:DiscussionTools#Talk_pages_permalinking|on Mediawiki.org]].&lt;!-- The Diff post will be published on Monday morning UTC--&gt; [https://phabricator.wikimedia.org/T302011]
* There are some improvements to the CAPTCHA to make it harder for spam bots and scripts to bypass it. If you have feedback on this change, please comment on [[phab:T141490|the task]]. Staff are monitoring metrics related to the CAPTCHA, as well as secondary metrics such as account creations and edit counts.

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.16|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-01-30|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-01-31|en}}. It will be on all wikis from {{#time:j xg|2024-02-01|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] On February 1, a link will be added to the &quot;Tools&quot; menu to download a [[w:en:QR code|QR code]] that links to the page you are viewing. There will also be a new [[{{#special:QrCode}}]] page to create QR codes for any Wikimedia URL. This addresses the [[m:Community Wishlist Survey 2023/Mobile and apps/Add ability to share QR code for a page in any Wikimedia project|#19 most-voted wish]] from the [[m:Community Wishlist Survey 2023/Results|2023 Community Wishlist Survey]]. [https://phabricator.wikimedia.org/T329973]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] [[mw:Special:MyLanguage/Extension:Gadgets|Gadgets]] which only work in some skins have sometimes used the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;targets&lt;/code&gt;&lt;/bdi&gt; option to limit where you can use them. This will stop working this week. You should use the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;skins&lt;/code&gt;&lt;/bdi&gt; option instead. [https://phabricator.wikimedia.org/T328497]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/05|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W05&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:31, 29 January 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26137870 --&gt;

== Wikipedia translation of the week: 2024-06 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Timurid architecture]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Gur-e-Amir Mausolueum - Samarkand - Uzbekistan (7488414078).jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Timurid architecture''' was an important stage in the architectural history of Iran and Central Asia during the late 14th and 15th centuries. The Timurid Empire (1370–1507), founded by Timur (d. 1405) and conquering most of this region, oversaw a cultural renaissance. In architecture, the Timurid dynasty patronized the construction of palaces, mausoleums, and religious monuments across the region. Their architecture is distinguished by its grand scale, luxurious decoration in tilework, and sophisticated geometric vaulting. This architectural style, along with other aspects of Timurid art, spread across the empire and subsequently influenced the architecture of other empires from the Middle East to the Indian subcontinent. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] [[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:23, 5 February 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26169542 --&gt;

== Tech News: 2024-06 ==

&lt;section begin=&quot;technews-2024-W06&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/06|Translations]] are available.

'''Recent changes'''
*The mobile site history pages now use the same HTML as the desktop history pages. If you hear of any problems relating to mobile history usage please point them to [[phab:T353388|the phabricator task]].
*On most wikis, admins can now block users from making specific actions. These actions are: uploading files, creating new pages, moving (renaming) pages, and sending thanks. The goal of this feature is to allow admins to apply blocks that are adequate to the blocked users' activity. [[m:Special:MyLanguage/Community health initiative/Partial blocks#action-blocks|Learn more about &quot;action blocks&quot;]]. [https://phabricator.wikimedia.org/T242541][https://phabricator.wikimedia.org/T280531]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.17|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-02-06|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-02-07|en}}. It will be on all wikis from {{#time:j xg|2024-02-08|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* Talk pages permalinks that included diacritics and non-Latin script were malfunctioning. This issue is fixed. [https://phabricator.wikimedia.org/T356199]

'''Future changes'''
* [[m:WMDE Technical Wishes/ReferencePreviews#24WPs|24 Wikipedias]] with [[mw:Special:MyLanguage/Reference_Tooltips|Reference Tooltips]] as a default gadget are encouraged to remove that default flag. This would make [[mw:Special:MyLanguage/Help:Reference_Previews|Reference Previews]] the new default for reference popups, leading to a more consistent experience across wikis. For [[m:WMDE Technical Wishes/ReferencePreviews#46WPs|46 Wikipedias]] with less than 4 interface admins, the change is already scheduled for mid-February, [[m:Talk:WMDE Technical Wishes/ReferencePreviews#Reference Previews to become the default for previewing references on more wikis.|unless there are concerns]]. The older Reference Tooltips gadget will still remain usable and will override this feature, if it is available on your wiki and you have enabled it in your settings. [https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/ReferencePreviews#Reference_Previews_to_become_the_default_for_previewing_references_on_more_wikis][https://phabricator.wikimedia.org/T355312]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/06|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W06&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:22, 5 February 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26180971 --&gt;

== Wikipedia translation of the week: 2024-07 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Adoration of the Magi (Fra Angelico and Filippo Lippi)]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Fra Angelico, Fra Filippo Lippi, The Adoration of the Magi.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''''Adoration of the Magi''''' is a tondo, or circular painting, of the Adoration of the Magi assumed to be that recorded in 1492 in the Palazzo Medici Riccardi in Florence as by Fra Angelico. It dates from the mid-15th century and is now in the National Gallery of Art in Washington D.C. Most art historians think that Filippo Lippi painted more of the original work, and that it was added to some years after by other artists, as well as including work by assistants in the workshops of both the original masters. It has been known as the Washington Tondo and Cook Tondo after Herbert Cook, and this latter name in particular continues to be used over 50 years after the painting left the Cook collection. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 07:00, 12 February 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26187446 --&gt;

== Tech News: 2024-07 ==

&lt;section begin=&quot;technews-2024-W07&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/07|Translations]] are available.

'''Recent changes'''
*  The [[d:Wikidata:SPARQL query service/WDQS graph split|WDQS Graph Split experiment]] is working and loaded onto 3 test servers. The team in charge is testing the split's impact and requires feedback from WDQS users through the UI or programmatically in different channels. [https://www.wikidata.org/wiki/Wikidata_talk:SPARQL_query_service/WDQS_graph_split][https://phabricator.wikimedia.org/T356773][https://www.wikidata.org/wiki/User:Sannita_(WMF)] Users' feedback will validate the impact of various use cases and workflows around the Wikidata Query service. [https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update/October_2023_scaling_update][https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual#Federation]

'''Problems'''
*There was a bug that affected the appearance of visited links when using mobile device to access wiki sites. It made the links appear black; [[phab:T356928|this issue]] is fixed.  

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.18|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-02-13|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-02-14|en}}. It will be on all wikis from {{#time:j xg|2024-02-15|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] As work continues on the grid engine deprecation,[https://wikitech.wikimedia.org/wiki/News/Toolforge_Grid_Engine_deprecation] tools on the grid engine will be stopped starting on February 14th, 2024. If you have tools actively migrating you can ask for an extension so they are not stopped. [https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge#Communication_and_support] 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/07|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W07&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 05:49, 13 February 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26223994 --&gt;

== Wikipedia translation of the week: 2024-08 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:nl:Graf met de handjes]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Weg langs het kerkhof tegenover 1, Roermond.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The monument '''Van Gorkum-Van Aefferden''', more well known as the &quot;'''grave with the little hands'''&quot; is a monumental Tombstone in the Dutch city of Roermond.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] [[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 13:24, 19 February 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26260848 --&gt;

== Tech News: 2024-08 ==

&lt;section begin=&quot;technews-2024-W08&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/08|Translations]] are available.

'''Recent changes'''
* If you have the &quot;{{int:Tog-enotifwatchlistpages}}&quot; option enabled, edits by bot accounts no longer trigger notification emails. Previously, only minor edits would not trigger the notification emails. [https://phabricator.wikimedia.org/T356984]
* There are changes to how user and site scripts load for [[mw:Special:MyLanguage/Skin:Vector/2022| Vector 2022]] on specific wikis. The changes impacted the following Wikis: all projects with [[mw:Special:MyLanguage/Skin:Vector|Vector legacy]] as the default skin, Wikivoyage, and Wikibooks. Other wikis will be affected over the course of the next three months. Gadgets are not impacted. If you have been affected or want to minimize the impact on your project, see [[Phab:T357580| this ticket]]. Please coordinate and take action proactively.
*Newly auto-created accounts (the accounts you get when you visit a new wiki) now have the same local notification preferences as users who freshly register on that wiki. It is effected in four notification types listed in the [[phab:T353225|task's description]].
*The maximum file size when using [[c:Special:MyLanguage/Commons:Upload_Wizard|Upload Wizard]] is now 5 GiB. [https://phabricator.wikimedia.org/T191804]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.19|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-02-20|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-02-21|en}}. It will be on all wikis from {{#time:j xg|2024-02-22|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Selected tools on the grid engine have been [[wikitech:News/Toolforge_Grid_Engine_deprecation|stopped]] as we prepare to shut down the grid on March 14th, 2024. The tool's code and data have not been deleted. If you are a maintainer and you want your tool re-enabled reach out to the [[wikitech:Portal:Toolforge/About_Toolforge#Communication_and_support|team]]. Only tools that have asked for extension are still running on the grid.
* The CSS &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;[https://developer.mozilla.org/en-US/docs/Web/CSS/filter filter]&lt;/code&gt;&lt;/bdi&gt; property can now be used in HTML &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;style&lt;/code&gt;&lt;/bdi&gt; attributes in wikitext. [https://phabricator.wikimedia.org/T308160]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/08|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W08&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 15:37, 19 February 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26254282 --&gt;

== Wikipedia translation of the week: 2024-09 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Doorway effect]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''doorway effect''' is a known psychological event where a person's short-term memory declines when passing through a doorway moving from one location to another when it would not if they had remained in the same place. People experience this effect by forgetting what they were going to do, thinking about, or planning upon entering a different room. This is thought to be due to the change in one's physical environment, which is used to distinguish boundaries between remembered events: memories of events encountered in the present environment are more accessible than those beyond it. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:30, 26 February 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26260848 --&gt;

== Tech News: 2024-09 ==

&lt;section begin=&quot;technews-2024-W09&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/09|Translations]] are available.

'''Recent changes'''
* The [[mw:Special:MyLanguage/VisualEditor_on_mobile|mobile visual editor]] is now the default editor for users who never edited before, at a small group of wikis. [[mw:Special:MyLanguage/VisualEditor_on_mobile/VE_mobile_default#A/B_test_results| Research ]] shows that users using this editor are slightly more successful publishing the edits they started, and slightly less successful publishing non-reverted edits. Users who defined the wikitext editor as their default on desktop will get the wikitext editor on mobile for their first edit on mobile as well. [https://phabricator.wikimedia.org/T352127]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The [[mw:Special:MyLanguage/ResourceLoader/Core modules#mw.config|mw.config]] value &lt;code&gt;wgGlobalGroups&lt;/code&gt; now only contains groups that are active in the wiki. Scripts no longer have to check whether the group is active on the wiki via an API request. A code example of the above is: &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;if (/globalgroupname/.test(mw.config.get(&quot;wgGlobalGroups&quot;)))&lt;/code&gt;&lt;/bdi&gt;. [https://phabricator.wikimedia.org/T356008]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.20|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-02-27|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-02-28|en}}. It will be on all wikis from {{#time:j xg|2024-02-29|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''Future changes'''
* The right to change [[mw:Special:MyLanguage/Manual:Tags|edit tags]] (&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;changetags&lt;/code&gt;&lt;/bdi&gt;) will be removed from users in Wikimedia sites, keeping it by default for admins and bots only. Your community can ask to retain the old configuration on your wiki before this change happens. Please indicate in [[phab:T355639|this ticket]] to keep it for your community before the end of March 2024.
'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/09|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W09&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:23, 26 February 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26294125 --&gt;

== Wikipedia translation of the week: 2024-10 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Sissieretta Jones]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:1899 poster of Mme. M. Sissieretta Jones.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Matilda Sissieretta Joyner Jones''' (January 5, 1868, or 1869 – June 24, 1933) was an American soprano. She sometimes was called &quot;The Black Patti&quot; in reference to Italian opera singer Adelina Patti. Jones' repertoire included grand opera, light opera, and popular music 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] [[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:33, 4 March 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26313143 --&gt;

== Tech News: 2024-10 ==

&lt;section begin=&quot;technews-2024-W10&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/10|Translations]] are available.

'''Recent changes'''
* The &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;Special:Book&lt;/code&gt;&lt;/bdi&gt; page (as well as the associated &quot;Create a book&quot; functionality) provided by the old [[mw:Special:MyLanguage/Extension:Collection|Collection extension]] has been removed from all Wikisource wikis, as it was broken. This does not affect the ability to download normal books, which is provided by the [[mw:Special:MyLanguage/Extension:Wikisource|Wikisource extension]]. [https://phabricator.wikimedia.org/T358437]
* [[m:Wikitech|Wikitech]] now uses the next-generation [[mw:Special:MyLanguage/Parsoid|Parsoid]] wikitext parser by default to generate all pages in the Talk namespace.  Report any problems on the [[mw:Talk:Parsoid/Parser_Unification/Known_Issues|Known Issues discussion page]]. You can use the [[mw:Special:MyLanguage/Extension:ParserMigration|ParserMigration]] extension to control the use of Parsoid; see the [[mw:Special:MyLanguage/Help:Extension:ParserMigration|ParserMigration help documentation]] for more details.
* Maintenance on [https://etherpad.wikimedia.org etherpad] is completed. If you encounter any issues, please indicate in [[phab:T316421|this ticket]].
* [[File:Octicons-tools.svg|12px|link=|alt=| Advanced item]] [[mw:Special:MyLanguage/Extension:Gadgets|Gadgets]] allow interface admins to create custom features with CSS and JavaScript. The &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;Gadget&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;Gadget_definition&lt;/code&gt;&lt;/bdi&gt; namespaces and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;gadgets-definition-edit&lt;/code&gt;&lt;/bdi&gt; user right were reserved for an experiment in 2015, but were never used. These were visible on Special:Search and Special:ListGroupRights. The unused namespaces and user rights are now removed. No pages are moved, and no changes need to be made. [https://phabricator.wikimedia.org/T31272]
* A usability improvement to the &quot;Add a citation&quot; in Wikipedia workflow has been made, the insert button was moved to the popup header. [https://phabricator.wikimedia.org/T354847]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.21|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-03-05|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-03-06|en}}. It will be on all wikis from {{#time:j xg|2024-03-07|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''Future changes'''
*  All wikis will be read-only for a few minutes on March 20. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [https://phabricator.wikimedia.org/T358233]
* The HTML markup of headings and section edit links will be changed later this year to improve accessibility. See [[mw:Special:MyLanguage/Heading_HTML_changes|Heading HTML changes]] for details. The new markup will be the same as in the new Parsoid wikitext parser. You can test your gadget or stylesheet with the new markup if you add &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;?useparsoid=1&lt;/code&gt;&lt;/bdi&gt; to your URL ([[mw:Special:MyLanguage/Help:Extension:ParserMigration#Selecting_a_parser_using_a_URL_query_string|more info]]) or turn on Parsoid read views in your user options ([[mw:Special:MyLanguage/Help:Extension:ParserMigration#Enabling_via_user_preference|more info]]).
*

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/10|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W10&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:47, 4 March 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26329807 --&gt;

== Wikipedia translation of the week: 2024-11 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Preventative Coup of November 11]]'''&lt;br /&gt; &lt;small&gt;''([[:es:Golpe de Estado en Brasil de 1955]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Exército na casa de Café Filho.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Preventative Coup of November 11''' sometimes called the '''1955 Brazilian coup d'état''' or referred to as an &quot;anti-coup&quot; or a &quot;counter-coup&quot; (Portuguese: ''Novembrada, Movimento de 11 de Novembro, Contragolpe, Golpe Preventivo do Marechal Lott'') was a series of military and political events led by Henrique Teixeira Lott that resulted in Nereu Ramos assuming the presidency of Brazil until being peacefully succeeded by Juscelino Kubitschek a few months later. The bloodless coup removed Carlos Luz from the presidency because he was suspected of plotting to prevent Kubitschek from taking office. As a result of the tensions, Brazil had three presidents in the span of a single week.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] [[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:04, 11 March 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26366849 --&gt;

== Tech News: 2024-11 ==

&lt;section begin=&quot;technews-2024-W11&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/11|Translations]] are available.

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.22|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-03-12|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-03-13|en}}. It will be on all wikis from {{#time:j xg|2024-03-14|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* After consulting with various communities, the line height of the text on the [[mw:Special:MyLanguage/Skin:Minerva Neue|Minerva skin]] will be increased to its previous value of 1.65. Different options for typography can also be set using the options in the menu, as needed. [https://phabricator.wikimedia.org/T358498]
*The active link color in [[mw:Special:MyLanguage/Skin:Minerva Neue|Minerva]] will be changed to provide more consistency with our other platforms and best practices. [https://phabricator.wikimedia.org/T358516]
* [[c:Special:MyLanguage/Commons:Structured data|Structured data on Commons]] will no longer ask whether you want to leave the page without saving. This will prevent the “information you’ve entered may not be saved” popups from appearing when no information have been entered. It will also make file pages on Commons load faster in certain cases. However, the popups will be hidden even if information has indeed been entered. If you accidentally close the page before saving the structured data you entered, that data will be lost. [https://phabricator.wikimedia.org/T312315]

'''Future changes'''
* All wikis will be read-only for a few minutes on March 20. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [https://phabricator.wikimedia.org/T358233][https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/Server_switch]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/11|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W11&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:04, 11 March 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26374013 --&gt;

== Wikipedia translation of the week: 2024-12 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Hojang Taret]]'''&lt;br /&gt; &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Hojang Taret''' is a classical Meitei language play based on Euripides's ancient Greek tragedy The Phoenician Women. It is directed by Oasis Sougaijam and produced by The Umbilical Theatre in Imphal, Kangleipak. It depicts the moral ambiguities of conflict between brothers resulting to the ruination of the ancient city of Thebes. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] [[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:52, 18 March 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26366849 --&gt;

== Tech News: 2024-12 ==

&lt;section begin=&quot;technews-2024-W12&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/12|Translations]] are available.

'''Recent changes'''
* The notice &quot;Language links are at the top of the page&quot; that appears in the [[mw:Special:MyLanguage/Skin:Vector/2022|Vector 2022 skin]] main menu has been removed now that users have learned the new location of the Language switcher. [https://phabricator.wikimedia.org/T353619]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] [[m:Special:MyLanguage/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/IP_Info_feature|IP info feature]] displays data from Spur, an IP addresses database. Previously, the only data source for this feature was MaxMind. Now, IP info is more useful for patrollers. [https://phabricator.wikimedia.org/T341395]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The Toolforge Grid Engine services have been shut down after the final migration process from Grid Engine to Kubernetes. [https://wikitech.wikimedia.org/wiki/Obsolete:Toolforge/Grid][https://wikitech.wikimedia.org/wiki/News/Toolforge_Grid_Engine_deprecation][https://techblog.wikimedia.org/2022/03/14/toolforge-and-grid-engine/]
* Communities can now customize the default reasons for undeleting a page by creating [[MediaWiki:Undelete-comment-dropdown]]. [https://phabricator.wikimedia.org/T326746]

'''Problems'''
* [[m:Special:MyLanguage/WMDE_Technical_Wishes/RevisionSlider|RevisionSlider]] is an interface to interactively browse a page's history. Users in [[mw:Special:MyLanguage/Extension:RevisionSlider/Developing_a_RTL-accessible_feature_in_MediaWiki_-_what_we%27ve_learned_while_creating_the_RevisionSlider|right-to-left]] languages reported RevisionSlider reacting wrong to mouse clicks. This should be fixed now. [https://phabricator.wikimedia.org/T352169]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.23|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-03-19|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-03-20|en}}. It will be on all wikis from {{#time:j xg|2024-03-21|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* All wikis will be read-only for a few minutes on March 20. This is planned at [https://zonestamp.toolforge.org/1710943200 14:00 UTC]. [https://phabricator.wikimedia.org/T358233][https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/Server_switch]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/12|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W12&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 17:40, 18 March 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26410165 --&gt;

== Wikipedia translation of the week: 2024-13 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Magna Lykseth-Skogman]]'''&lt;br /&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Magna Lykseth in Tristan och Isolde at Kungliga Operan 1909 - SMV - GL164.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Magna Elvine Lykseth-Skogman''' (6 February 1874 – 13 November 1949), also known as Magna Lykseth-Schjerven, was a Norwegian-born Swedish operatic soprano. After making her début at the Royal Swedish Opera in 1901 as Santuzza in Cavalleria rusticana, she was engaged there until 1918 becoming the company's prima donna. She performed leading roles in a wide range of operas but is remembered in particular for her Wagnerian interpretations, creating Brünnhilde in the Swedish premières of Siegfried and Götterdämmerung, and Isolde in 1909. Considered to be one of the most outstanding Swedish opera singers of her generation, she was awarded the Litteris et Artibus medal in 1907 and became a member of the Royal Swedish Academy of Music in 1912 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] [[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:00, 25 March 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26447450 --&gt;

== Tech News: 2024-13 ==

&lt;section begin=&quot;technews-2024-W13&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/13|Translations]] are available.

'''Recent changes'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] An update was made on March 18th 2024 to how various projects load site, user JavaScript and CSS in [[mw:Special:MyLanguage/Skin:Vector/2022|Vector 2022 skin]]. A [[phab:T360384|checklist]] is provided for site admins to follow.

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.24|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-03-26|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-03-27|en}}. It will be on all wikis from {{#time:j xg|2024-03-28|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/13|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W13&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 18:57, 25 March 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26446209 --&gt;

== Wikipedia translation of the week: 2024-14 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Lidder Valley]]'''&lt;br /&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Pahalgam Valley.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Lidder Valley''' or Liddar Valley is a Himalayan sub-valley that forms the southeastern corner of Anantnag district in Indian-administered Kashmir. The Lidder River flows down the valley. The entrance to the valley lies 7 km northeast from Anantnag town and 62 km southeast from Srinagar, the summer capital of Jammu and Kashmir. It is a 40-km-long gorge valley with an average width of 3 km. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] [[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 03:15, 1 April 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26509189 --&gt;

== Tech News: 2024-14 ==

&lt;section begin=&quot;technews-2024-W14&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/14|Translations]] are available.

'''Recent changes'''
* Users of the [[mw:Special:MyLanguage/Reading/Web/Accessibility_for_reading|reading accessibility]] beta feature will notice that the default line height for the standard and large text options has changed. [https://phabricator.wikimedia.org/T359030]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.25|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-04-02|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-04-03|en}}. It will be on all wikis from {{#time:j xg|2024-04-04|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''Future changes'''
* The Wikimedia Foundation has an annual plan. The annual plan decides what the Wikimedia Foundation will work on. You can now read [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2024-2025/Product &amp; Technology OKRs#Draft Key Results|the draft key results]] for the Product and Technology department. They are suggestions for what results the Foundation wants from big technical changes from July 2024 to June 2025. You can [[m:Talk:Wikimedia Foundation Annual Plan/2024-2025/Product &amp; Technology OKRs|comment on the talk page]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/14|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W14&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 03:36, 2 April 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26462933 --&gt;

== Wikipedia translation of the week: 2024-15 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Operation Kraai]]'''&lt;br /&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Overzicht van het vliegveld te Djokja vanuit de 'Control Tower', Bestanddeelnr 5128.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Operation Kraai''' (Operation Crow) was a Dutch military offensive against the de facto Republic of Indonesia in December 1948 after negotiations failed. With the advantage of surprise the Dutch managed to capture the Indonesian Republic's temporary capital, Yogyakarta, and seized Indonesian leaders such as de facto Republican President Sukarno. This apparent military success was however followed by guerrilla warfare, while the violation of the Renville Agreement ceasefire diplomatically isolated the Dutch, leading to the Dutch–Indonesian Round Table Conference and recognition of the United States of Indonesia. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] [[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:47, 8 April 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26550154 --&gt;

== Tech News: 2024-15 ==

&lt;section begin=&quot;technews-2024-W15&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/15|Translations]] are available.

'''Recent changes'''
* Web browsers can use tools called [[:w:en:Browser extension|extensions]]. There is now a Chrome extension called [[m:Future Audiences/Experiment:Citation Needed|Citation Needed]] which you can use to see if an online statement is supported by a Wikipedia article. This is a small experiment to see if Wikipedia can be used this way. Because it is a small experiment, it can only be used in Chrome in English.
* [[File:Octicons-gift.svg|12px|link=|alt=|Wishlist item]] A new [[mw:Special:MyLanguage/Help:Edit Recovery|Edit Recovery]] feature has been added to all wikis, available as a [[Special:Preferences#mw-prefsection-editing|user preference]]. Once you enable it, your in-progress edits will be stored in your web browser, and if you accidentally close an editing window or your browser or computer crashes, you will be prompted to recover the unpublished text. Please leave any feedback on the [[m:Special:MyLanguage/Talk:Community Wishlist Survey 2023/Edit-recovery feature|project talk page]]. This was the #8 wish in the 2023 Community Wishlist Survey.
* Initial results of [[mw:Special:MyLanguage/Edit check|Edit check]] experiments [[mw:Special:MyLanguage/Edit_check#4_April_2024|have been published]]. Edit Check is now deployed as a default feature at [[phab:T342930#9538364|the wikis that tested it]]. [[mw:Talk:Edit check|Let us know]] if you want your wiki to be part of the next deployment of Edit check. [https://phabricator.wikimedia.org/T342930][https://phabricator.wikimedia.org/T361727]
* Readers using the [[mw:Special:MyLanguage/Skin:Minerva Neue|Minerva skin]] on mobile will notice there has been an improvement in the line height across all typography settings. [https://phabricator.wikimedia.org/T359029]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.42/wmf.26|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-04-09|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-04-10|en}}. It will be on all wikis from {{#time:j xg|2024-04-11|en}} ([[mw:MediaWiki 1.42/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* New accounts and logged-out users will get the [[mw:Special:MyLanguage/VisualEditor|visual editor]] as their default editor on mobile. This deployment is made at all wikis except for the English Wikipedia. [https://phabricator.wikimedia.org/T361134]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/15|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W15&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:38, 8 April 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26564838 --&gt;

== Wikipedia translation of the week: 2024-16 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:ru:Павильон Росси]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Rossi Pavilion]])&amp;#32;([[:fr:Pavillon Rossi]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Rossi's Pavilion in Mikhailovsky Garden. Saint-Petersburg. 1825..jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Rossi Pavilion''' (Russian: Павильон Росси) is a pavilion on the bank of the Moyka River in the Mikhailovsky Garden in Saint Petersburg. It was designed by architect Carlo Rossi in the early 1820s and built in 1825 during his redevelopment of the garden. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] [[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:53, 15 April 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26565118 --&gt;

== Tech News: 2024-16 ==

&lt;section begin=&quot;technews-2024-W16&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/16|Translations]] are available.

'''Problems'''
* Between 2 April and 8 April, on wikis using [[mw:Special:MyLanguage/Extension:FlaggedRevs|Flagged Revisions]], the &quot;{{Int:tag-mw-reverted}}&quot; tag was not applied to undone edits. In addition, page moves, protections and imports were not autoreviewed. This problem is now fixed. [https://phabricator.wikimedia.org/T361918][https://phabricator.wikimedia.org/T361940]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.1|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-04-16|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-04-17|en}}. It will be on all wikis from {{#time:j xg|2024-04-18|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* [[mw:Special:MyLanguage/Help:Magic words#DEFAULTSORT|Default category sort keys]] will now affect categories added by templates placed in [[mw:Special:MyLanguage/Help:Cite|footnotes]]. Previously footnotes used the page title as the default sort key even if a different default sort key was specified (category-specific sort keys already worked). [https://phabricator.wikimedia.org/T40435]
* A new variable &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;page_last_edit_age&lt;/code&gt;&lt;/bdi&gt; will be added to [[Special:AbuseFilter|abuse filters]]. It tells how many seconds ago the last edit to a page was made. [https://phabricator.wikimedia.org/T269769]

'''Future changes'''
* Volunteer developers are kindly asked to update the code of their tools and features to handle [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|temporary accounts]]. [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts/For developers/2024-04 CTA|Learn more]].
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Four database fields will be removed from database replicas (including [[quarry:|Quarry]]). This affects only the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;abuse_filter&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;abuse_filter_history&lt;/code&gt;&lt;/bdi&gt; tables. Some queries might need to be updated. [https://phabricator.wikimedia.org/T361996]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/16|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W16&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:29, 15 April 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26564838 --&gt;

== Wikipedia translation of the week: 2024-17 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Devorà Ascarelli]]'''&lt;br /&gt; &lt;small&gt;''([[:it:Debora Ascarelli]])&amp;#32;([[:es:Devorà Ascarelli]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Devorà Ascarelli''' was a 16th-century Italian poet living in Rome, Italy. Ascarelli may have been the first Jewish woman to have a book of her own work published. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] 01:35, 22 April 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26624302 --&gt;

== Tech News: 2024-17 ==

&lt;section begin=&quot;technews-2024-W17&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/17|Translations]] are available.

'''Recent changes'''
* Starting this week, newcomers editing Wikipedia [[mw:Special:MyLanguage/Growth/Positive reinforcement#Leveling up 3|will be encouraged]] to try structured tasks. [[mw:Special:MyLanguage/Growth/Feature summary#Newcomer tasks|Structured tasks]] have been shown to [[mw:Special:MyLanguage/Growth/Personalized first day/Structured tasks/Add a link/Experiment analysis, December 2021|improve newcomer activation and retention]]. [https://phabricator.wikimedia.org/T348086]
* You can [[m:Special:MyLanguage/Coolest Tool Award|nominate your favorite tools]] for the fifth edition of the Coolest Tool Award. Nominations will be open until May 10. 

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.2|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-04-23|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-04-24|en}}. It will be on all wikis from {{#time:j xg|2024-04-25|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''Future changes'''
* This is the last warning that by the end of May 2024 the Vector 2022 skin will no longer share site and user scripts/styles with old Vector. For user-scripts that you want to keep using on Vector 2022, copy the contents of [[{{#special:MyPage}}/vector.js]] to [[{{#special:MyPage}}/vector-2022.js]]. There are [[mw:Special:MyLanguage/Reading/Web/Desktop Improvements/Features/Loading Vector 2010 scripts|more technical details]] available. Interface administrators who foresee this leading to lots of technical support questions may wish to send a mass message to your community, as was done on French Wikipedia. [https://phabricator.wikimedia.org/T362701]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/17|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W17&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:28, 22 April 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26647188 --&gt;

== Wikipedia translation of the week: 2024-18 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:1989 Serbian general election]]'''&lt;br /&gt; &lt;small&gt;''([[:sr:Председнички избори у Србији 1989.]])&amp;#32;([[:vi:Tổng tuyển cử Serbia 1989]])''&lt;/small&gt;&lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Parliament of SR Serbia (1989–1991).svg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''General elections were held in Serbia''', a constituent federal unit of SFR Yugoslavia, on 12 November 1989 to elect the president of the presidency of the Socialist Republic of Serbia and delegates of the Assembly of SR Serbia. Voting for delegates also took place on 10 and 30 November 1989. In addition to the general elections, local elections were held simultaneously. These were the first direct elections conducted after the adoption of the 1974 Yugoslav Constitution and the delegate electoral system, and the last elections conducted under a one-party system. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] [[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:32, 29 April 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26624302 --&gt;

== Tech News: 2024-18 ==

&lt;section begin=&quot;technews-2024-W18&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/18|Translations]] are available.

'''Recent changes'''

[[File:Talk_pages_default_look_(April_2023).jpg|thumb|alt=Screenshot of the visual improvements made on talk pages|Example of a talk page with the new design, in French.]]
* The appearance of talk pages changed for the following wikis: {{int:project-localized-name-azwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-bnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-dewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-fawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hiwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-idwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nlwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ptwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-rowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-thwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-trwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ukwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-viwiki/en}}. These wikis participated to a test, where 50% of users got the new design, for one year. As this test [[Mw:Special:MyLanguage/Talk pages project/Usability/Analysis|gave positive results]], the new design is deployed on these wikis as the default design. It is possible to opt-out these changes [[Special:Preferences#mw-prefsection-editing|in user preferences]] (&quot;{{int:discussiontools-preference-visualenhancements}}&quot;). The deployment will happen at all wikis in the coming weeks. [https://phabricator.wikimedia.org/T341491]
* Seven new wikis have been created: 
** a {{int:project-localized-name-group-wikipedia}} in [[d:Q33014|Betawi]] ([[w:bew:|&lt;code&gt;w:bew:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T357866]
** a {{int:project-localized-name-group-wikipedia}} in [[d:Q35708|Kusaal]] ([[w:kus:|&lt;code&gt;w:kus:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T359757]
** a {{int:project-localized-name-group-wikipedia}} in [[d:Q35513|Igala]] ([[w:igl:|&lt;code&gt;w:igl:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T361644]
** a {{int:project-localized-name-group-wiktionary}} in [[d:Q33541|Karakalpak]] ([[wikt:kaa:|&lt;code&gt;wikt:kaa:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T362135]
** a {{int:project-localized-name-group-wikisource}} in [[d:Q9228|Burmese]] ([[s:my:|&lt;code&gt;s:my:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T361085]
** a {{int:project-localized-name-group-wikisource}} in [[d:Q9237|Malay]] ([[s:ms:|&lt;code&gt;s:ms:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T363039]
** a {{int:project-localized-name-group-wikisource}} in [[d:Q8108|Georgian]] ([[s:ka:|&lt;code&gt;s:ka:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T363085]
* You can now [https://translatewiki.net/wiki/Support#Early_access:_Watch_Message_Groups_on_Translatewiki.net watch message groups/projects] on [[m:Special:MyLanguage/translatewiki.net|Translatewiki.net]]. Initially, this feature will notify you of added or deleted messages in these groups. [https://phabricator.wikimedia.org/T348501]
* Dark mode is now available on all wikis, on mobile web for logged-in users who opt into the [[Special:MobileOptions|advanced mode]]. This is the early release of the feature. Technical editors are invited to [https://night-mode-checker.wmcloud.org/ check for accessibility issues on wikis]. See [[mw:Special:MyLanguage/Reading/Web/Accessibility for reading/Updates/2024-04|more detailed guidelines]].

'''Problems'''
* [[mw:Special:MyLanguage/Help:Extension:Kartographer|Kartographer]] maps can use an alternative visual style without labels, by using &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;mapstyle=&quot;osm&quot;&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;. This wasn't working in previews, creating the wrong impression that it wasn't supported. This has now been fixed. [https://phabricator.wikimedia.org/T362531]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.3|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-04-30|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-05-01|en}}. It will be on all wikis from {{#time:j xg|2024-05-02|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/18|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W18&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 03:34, 30 April 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26689057 --&gt;

== Wikipedia translation of the week: 2024-19 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:#DDDDDD; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Heinrich Bünting]]'''&lt;br /&gt; &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Heinrich Bünting''' (1545 – 1606) was a Protestant pastor and theologian. He is best known for his book of woodcut maps titled Itinerarium Sacrae Scripturae (Travel book through Holy Scripture) first published in 1581. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:27, 6 May 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26624302 --&gt;

== Tech News: 2024-19 ==

&lt;section begin=&quot;technews-2024-W19&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/19|Translations]] are available.

'''Recent changes'''
[[File:Talk_pages_default_look_(April_2023).jpg|thumb|alt=Screenshot of the visual improvements made on talk pages|Example of a talk page with the new design, in French.]]
* The appearance of talk pages changed for all wikis, except for Commons, Wikidata and most Wikipedias ([[m:Special:MyLanguage/Tech/News/2024/18|a few]] have already received this design change). You can read the detail of the changes [[diffblog:2024/05/02/making-talk-pages-better-for-everyone/|on ''Diff'']]. It is possible to opt-out these changes [[Special:Preferences#mw-prefsection-editing|in user preferences]] (&quot;{{int:discussiontools-preference-visualenhancements}}&quot;). The deployment will happen at remaining wikis in the coming weeks. [https://phabricator.wikimedia.org/T352087][https://phabricator.wikimedia.org/T319146]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Interface admins now have greater control over the styling of article components on mobile with the introduction of the &lt;code&gt;SiteAdminHelper&lt;/code&gt;. More information on how styles can be disabled can be found [[mw:Special:MyLanguage/Extension:WikimediaMessages#Site_admin_helper|at the extension's page]]. [https://phabricator.wikimedia.org/T363932]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] [[m:Special:MyLanguage/Wikimedia Enterprise|Wikimedia Enterprise]] has added article body sections in JSON format and a curated short description field to the existing parsed Infobox. This expansion to the API is also available via Wikimedia Cloud Services. [https://enterprise.wikimedia.com/blog/article-sections-and-description/]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.4|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-05-07|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-05-08|en}}. It will be on all wikis from {{#time:j xg|2024-05-09|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* When you look at the Special:Log page, the first view is labelled &quot;All public logs&quot;, but it only shows some logs. This label will now say &quot;Main public logs&quot;. [https://phabricator.wikimedia.org/T237729]

'''Future changes'''
* A new service will be built to replace [[mw:Special:MyLanguage/Extension:Graph|Extension:Graph]]. Details can be found in [[mw:Special:MyLanguage/Extension:Graph/Plans|the latest update]] regarding this extension.
* Starting May 21, English Wikipedia and German Wikipedia will get the possibility to activate &quot;[[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]]&quot;. This is part of the [[phab:T304110|progressive deployment of this tool to all Wikipedias]]. These communities can [[mw:Special:MyLanguage/Growth/Community configuration|activate and configure the feature locally]]. [https://phabricator.wikimedia.org/T308144]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/19|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W19&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 16:45, 6 May 2024 (UTC)
&lt;!-- Message sent by User:Trizek (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26729363 --&gt;

== Wikipedia translation of the week: 2024-20 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background:var(--background-color-backdrop-dark, #DDDDDD); border:1px solid #BBBBBB; color:var(--color-inverted, #000000); padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Ruyan (district)]]'''&lt;br /&gt; &lt;small&gt;''([[:fa:رویان (طبرستان)]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Northern Iran and its surroundings during the Iranian intermezzo.svg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Ruyan''' (Persian: رویان), later known as Rustamdar (رستمدار), was the name of a mountainous district that encompassed the western part of Tabaristan/Mazandaran, a region on the Caspian coast of northern Iran. In Iranian mythology, Ruyan appears as one of the places that the legendary archer Arash shot his arrow from, reaching the edge of Khorasan to mark the border between Iran and Turan. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:39, 13 May 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26755244 --&gt;

== Tech News: 2024-20 ==

&lt;section begin=&quot;technews-2024-W20&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/20|Translations]] are available.

'''Recent changes'''
* On Wikisource there is a special page listing pages of works without corresponding scan images. Now you can use the new magic word &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;__EXPECTWITHOUTSCANS__&lt;/code&gt;&lt;/bdi&gt; to exclude certain pages (list of editions or translations of works) from that list. [https://phabricator.wikimedia.org/T344214]
* If you use the [[Special:Preferences#mw-prefsection-editing|user-preference]] &quot;{{int:tog-uselivepreview}}&quot;, then the template-page feature &quot;{{int:Templatesandbox-editform-legend}}&quot; will now also work without reloading the page. [https://phabricator.wikimedia.org/T136907]
* [[mw:Special:Mylanguage/Extension:Kartographer|Kartographer]] maps can now specify an alternative text via the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;alt=&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; attribute. This is identical in usage to the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;alt=&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; attribute in the [[mw:Special:MyLanguage/Help:Images#Syntax|image and gallery syntax]]. An exception for this feature is wikis like Wikivoyage where the miniature maps are interactive. [https://phabricator.wikimedia.org/T328137]
* The old [[mw:Special:MyLanguage/Extension:GuidedTour|Guided Tour]] for the &quot;[[mw:Special:MyLanguage/Edit Review Improvements/New filters for edit review|New Filters for Edit Review]]&quot; feature has been removed. It was created in 2017 to show people with older accounts how the interface had changed, and has now been seen by most of the intended people. [https://phabricator.wikimedia.org/T217451]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.5|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-05-14|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-05-15|en}}. It will be on all wikis from {{#time:j xg|2024-05-16|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The [[{{#special:search}}]] results page will now use CSS flex attributes, for better accessibility, instead of a table. If you have a gadget or script that adjusts search results, you should update your script to the new HTML structure. [https://phabricator.wikimedia.org/T320295]

'''Future changes'''
* In the Vector 2022 skin, main pages will be displayed at full width (like special pages). The goal is to keep the number of characters per line large enough. This is related to the coming changes to typography in Vector 2022. [[mw:Special:MyLanguage/Reading/Web/Accessibility for reading/Updates|Learn more]]. [https://phabricator.wikimedia.org/T357706]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Two columns of the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;[[mw:Special:MyLanguage/Manual:pagelinks table|pagelinks]]&lt;/code&gt;&lt;/bdi&gt; database table (&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;pl_namespace&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;pl_title&lt;/code&gt;&lt;/bdi&gt;) are being dropped soon. Users must use two columns of the new &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;[[mw:special:MyLanguage/Manual:linktarget table|linktarget]]&lt;/code&gt;&lt;/bdi&gt; table instead (&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;lt_namespace&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;lt_title&lt;/code&gt;&lt;/bdi&gt;). In your existing SQL queries:
*# Replace &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;JOIN pagelinks&lt;/code&gt;&lt;/bdi&gt; with &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;JOIN linktarget&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;pl_&lt;/code&gt;&lt;/bdi&gt; with &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;lt_&lt;/code&gt;&lt;/bdi&gt; in the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;ON&lt;/code&gt;&lt;/bdi&gt; statement
*# Below that add &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;JOIN pagelinks ON lt_id = pl_target_id&lt;/code&gt;&lt;/bdi&gt;
** See &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[phab:T222224]]&lt;/bdi&gt; for technical reasoning. [https://phabricator.wikimedia.org/T222224][https://phabricator.wikimedia.org/T299947]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/20|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W20&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:59, 13 May 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26762074 --&gt;

== Wikipedia translation of the week: 2024-21 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: #f8f9fa; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Turlough (lake)]]'''&lt;br /&gt; &lt;small&gt;''([[:de:Turlough]])&amp;#32;([[:no:Turlough]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Carran Turlough.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
A '''turlough''' is a seasonal or periodic water body found mostly in limestone karst areas of Ireland, west of the River Shannon. [...] The water bodies fill and empty with the changes in the level of the water table, usually being very low or empty during summer and autumn and full in the winter. As groundwater levels drop the water drains away underground through cracks in the karstic limestone.  

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:31, 20 May 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26789673 --&gt;

== Tech News: 2024-21 ==

&lt;section begin=&quot;technews-2024-W21&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/21|Translations]] are available.

'''Recent changes'''
* The [[mw:Special:MyLanguage/Extension:Nuke|Nuke]] feature, which enables administrators to mass delete pages, will now correctly delete pages which were moved to another title. [https://phabricator.wikimedia.org/T43351]
* New changes have been made to the UploadWizard in Wikimedia Commons: the overall layout has been improved, by following new styling and spacing for the form and its fields; the headers and helper text for each of the fields was changed; the Caption field is now a required field, and there is an option for users to copy their caption into the media description. [https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wizard_Improvements#Changes_to_%22Describe%22_workflow][https://phabricator.wikimedia.org/T361049]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.6|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-05-21|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-05-22|en}}. It will be on all wikis from {{#time:j xg|2024-05-23|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]]  The HTML used to render all headings [[mw:Heading_HTML_changes|is being changed to improve accessibility]]. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and [[phab:T13555|report any related problems]] so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a [[phab:T337286|Gadget API for adding buttons to section titles]] if that would be helpful to tool creators, and would appreciate any input you have on that.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/21|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W21&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:04, 20 May 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26786311 --&gt;

== Wikipedia translation of the week: 2024-22 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: #f8f9fa; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Geiranger Church]]'''&lt;br /&gt; &lt;small&gt;''([[:no:Geiranger kirke]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----
[[File:Iglesia parroquial, Geiranger, Noruega, 2019-09-07, DD 84-97 PAN.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Geiranger Church''' (Norwegian: Geiranger kyrkje) is a parish church of the Church of Norway in Stranda Municipality in Møre og Romsdal county, Norway. It is located in the village of Geiranger, and the end of the famous Geirangerfjorden. It is the church for the Geiranger parish which is part of the Nordre Sunnmøre prosti (deanery) in the Diocese of Møre. The white, wooden church was built in an octagonal design in 1842 using plans drawn up by the architect Hans Klipe. The church seats about 165 people. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:48, 27 May 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26828106 --&gt;

== Tech News: 2024-22 ==

&lt;section begin=&quot;technews-2024-W22&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/22|Translations]] are available.

'''Recent changes'''
* Several bugs related to the latest updates to the UploadWizard on Wikimedia Commons have been fixed. For more information, see [[:phab:T365107|T365107]] and [[:phab:T365119|T365119]].
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] In March 2024 a new [[mw:ResourceLoader/Core_modules#addPortlet|addPortlet]] API was added to allow gadgets to create new portlets (menus) in the skin. In certain skins this can be used to create dropdowns. Gadget developers are invited to try it and [[phab:T361661|give feedback]].
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Some CSS in the Minerva skin has been removed to enable easier community configuration. Interface editors should check the rendering on mobile devices for aspects related to the classes: &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;.collapsible&lt;/code&gt;&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;.multicol&lt;/code&gt;&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;.reflist&lt;/code&gt;&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;.coordinates&lt;/code&gt;&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;.topicon&lt;/code&gt;&lt;/bdi&gt;. [[phab:T361659|Further details are available on replacement CSS]] if it is needed.

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.7|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-05-28|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-05-29|en}}. It will be on all wikis from {{#time:j xg|2024-05-30|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* When you visit a wiki where you don't yet have a local account, local rules such as edit filters can sometimes prevent your account from being created. Starting this week, MediaWiki takes your global rights into account when evaluating whether you can override such local rules. [https://phabricator.wikimedia.org/T316303]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/22|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W22&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:15, 28 May 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26832205 --&gt;

== Wikipedia translation of the week: 2024-23 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: #f8f9fa; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Guillermo Larrazábal]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Guillermo Larrazábal Arzubide''' (10 February 1907 – 1983) was a Spanish stained glass artist who was active in Ecuador. He is considered Ecuador's most important stained glass artist. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:14, 3 June 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26828106 --&gt;

== Tech News: 2024-23 ==

&lt;section begin=&quot;technews-2024-W23&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/23|Translations]] are available.

'''Recent changes'''
* It is now possible for local administrators to add new links to the bottom of the site Tools menu without JavaScript. [[mw:Manual:Interface/Sidebar#Add or remove toolbox sections|Documentation is available]]. [https://phabricator.wikimedia.org/T6086]
* The message name for the definition of the tracking category of WikiHiero has changed from &quot;&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;MediaWiki:Wikhiero-usage-tracking-category&lt;/code&gt;&lt;/bdi&gt;&quot; to &quot;&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;MediaWiki:Wikihiero-usage-tracking-category&lt;/code&gt;&lt;/bdi&gt;&quot;. [https://gerrit.wikimedia.org/r/c/mediawiki/extensions/wikihiero/+/1035855]
* One new wiki has been created: a {{int:project-localized-name-group-wikipedia}} in [[d:Q5317225|Kadazandusun]] ([[w:dtp:|&lt;code&gt;w:dtp:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T365220]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.8|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-06-04|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-06-05|en}}. It will be on all wikis from {{#time:j xg|2024-06-06|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''Future changes'''
* Next week, on wikis with the Vector 2022 skin as the default, logged-out desktop users will be able to choose between different font sizes. The default font size will also be increased for them. This is to make Wikimedia projects easier to read. [[mw:Special:MyLanguage/Reading/Web/Accessibility for reading/Updates/2024-06 deployments|Learn more]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/23|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W23&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:35, 3 June 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26844397 --&gt;

== Tech News: 2024-24 ==

&lt;section begin=&quot;technews-2024-W24&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/24|Translations]] are available.

'''Recent changes'''
* The software used to render SVG files has been updated to a new version, fixing many longstanding bugs in SVG rendering. [https://phabricator.wikimedia.org/T265549]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The HTML used to render all headings [[mw:Heading HTML changes|is being changed to improve accessibility]]. It was changed last week in some skins (Vector legacy and Minerva). Please test gadgets on your wiki on these skins and [[phab:T13555|report any related problems]] so that they can be resolved before this change is made in Vector-2022. The developers are still considering the introduction of a [[phab:T337286|Gadget API for adding buttons to section titles]] if that would be helpful to tool creators, and would appreciate any input you have on that.
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The HTML markup used for citations by [[mw:Special:MyLanguage/Parsoid|Parsoid]] changed last week. In places where Parsoid previously added the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;mw-reference-text&lt;/code&gt;&lt;/bdi&gt; class, Parsoid now also adds the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;reference-text&lt;/code&gt;&lt;/bdi&gt; class for better compatibility with the legacy parser. [[mw:Specs/HTML/2.8.0/Extensions/Cite/Announcement|More details are available]]. [https://gerrit.wikimedia.org/r/1036705]

'''Problems'''
* There was a bug with the Content Translation interface that caused the tools menus to appear in the wrong location. This has now been fixed. [https://phabricator.wikimedia.org/T366374]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.9|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-06-11|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-06-12|en}}. It will be on all wikis from {{#time:j xg|2024-06-13|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The new version of MediaWiki includes another change to the HTML markup used for citations: [[mw:Special:MyLanguage/Parsoid|Parsoid]] will now generate a &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;&lt;span class=&quot;mw-cite-backlink&quot;&gt;&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; wrapper for both named and unnamed references for better compatibility with the legacy parser. Interface administrators should verify that gadgets that interact with citations are compatible with the new markup. [[mw:Specs/HTML/2.8.0/Extensions/Cite/Announcement|More details are available]]. [https://gerrit.wikimedia.org/r/1035809] 
* On multilingual wikis that use the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;&lt;translate&gt;&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; system, there is a feature that shows potentially-outdated translations with a pink background until they are updated or confirmed. From this week, confirming translations will be logged, and there is a new user-right that can be required for confirming translations if the community [[m:Special:MyLanguage/Requesting wiki configuration changes|requests it]]. [https://phabricator.wikimedia.org/T49177]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/24|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W24&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:20, 10 June 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26893898 --&gt;

== Wikipedia translation of the week: 2024-25 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: #f8f9fa; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:de:Magdalena Zeger]]'''&lt;br /&gt;  &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Magdalena Zeger''' ([mak.da.ˈleː.na ˈt͡seː.gɐ], * 1491; † 16. January 1568 in Kolding) was a calendar maker, astronomer and astrologist. Her Hamburg almanacs and forecasts from 1561 and 1563 have been preserved. Zeger's calendars are the first independent publications by a woman in the field of astronomy. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:29, 17 June 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26940351 --&gt;

== Tech News: 2024-25 ==

&lt;section begin=&quot;technews-2024-W25&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/25|Translations]] are available.

'''Recent changes'''
* People who attempt to add an external link in the visual editor will now receive immediate feedback if they attempt to link to a domain that a project has decided to block. Please see [[mw:Special:MyLanguage/Edit_check#11_June_2024|Edit check]] for more details. [https://phabricator.wikimedia.org/T366751]
* The new [[mw:Special:MyLanguage/Extension:CommunityConfiguration|Community Configuration extension]] is available [[testwiki:Special:CommunityConfiguration|on Test Wikipedia]]. This extension allows communities to customize specific features to meet their local needs. Currently only Growth features are configurable, but the extension will support other [[mw:Special:MyLanguage/Community_configuration#Use_cases|Community Configuration use cases]] in the future. [https://phabricator.wikimedia.org/T323811][https://phabricator.wikimedia.org/T360954]
* The dark mode [[Special:Preferences#mw-prefsection-betafeatures|beta feature]] is now available on category and help pages, as well as more special pages. There may be contrast issues. Please report bugs on the [[mw:Talk:Reading/Web/Accessibility_for_reading|project talk page]]. [https://phabricator.wikimedia.org/T366370]

'''Problems'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] Cloud Services tools were not available for 25 minutes last week. This was caused by a faulty hardware cable in the data center. [https://wikitech.wikimedia.org/wiki/Incidents/2024-06-11_WMCS_Ceph]
* Last week, styling updates were made to the Vector 2022 skin. This caused unforeseen issues with templates, hatnotes, and images. Changes to templates and hatnotes were reverted. Most issues with images were fixed. If you still see any, [[phab:T367463|report them here]]. [https://phabricator.wikimedia.org/T367480]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.10|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-06-18|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-06-19|en}}. It will be on all wikis from {{#time:j xg|2024-06-20|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* Starting June 18, the [[mw:Special:MyLanguage/Help:Edit check#ref|Reference Edit Check]] will be deployed to [[phab:T361843|a new set of Wikipedias]]. This feature is intended to help newcomers and to assist edit-patrollers by inviting people who are adding new content to a Wikipedia article to add a citation when they do not do so themselves. During [[mw:Special:MyLanguage/Edit_check#Reference_Check_A/B_Test|a test at 11 wikis]], the number of citations added [https://diff.wikimedia.org/?p=127553 more than doubled] when Reference Check was shown to people. Reference Check is [[mw:Special:MyLanguage/Edit check/Configuration|community configurable]]. [https://phabricator.wikimedia.org/T361843]&lt;!-- NOTE: THE DIFF BLOG WILL BE PUBLISHED ON MONDAY --&gt;
* [[m:Special:MyLanguage/Mailing_lists|Mailing lists]] will be unavailable for roughly two hours on Tuesday 10:00–12:00 UTC. This is to enable migration to a new server and upgrade its software. [https://phabricator.wikimedia.org/T367521]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/25|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W25&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:49, 17 June 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26911987 --&gt;

== Wikipedia translation of the week: 2024-26 ==

{| class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: #f8f9fa; border:1px solid #BBBBBB; color:#000000; padding .4em;&quot;
|-
|style=&quot;text-align:center;&quot;| The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Koreans in Micronesia]]'''&lt;br /&gt; &lt;small&gt;''([[:zh:朝鮮裔密克羅尼西亞人]])''&lt;/small&gt; &lt;/div&gt;

Please be bold and help translate this article!

----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Koreans in Micronesia''' used to form a significant population before World War II, when most of the region was ruled as the South Seas Mandate of the Empire of Japan; for example, they formed 7.3% of the population of Palau in 1943. However, after the area came under the control of the United States as the Trust Territory of the Pacific Islands, most Koreans returned to their homeland. As of 2013, about seven thousand South Korean expatriates &amp; immigrants and Korean Americans reside in the Marianas (Guam and the Commonwealth of the Northern Mariana Islands), which have remained under U.S. control, while only around two hundred South Korean expatriates reside in the independent countries of Micronesia. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 04:03, 24 June 2024 (UTC)''
&lt;/div&gt;
|}
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=26940351 --&gt;

== Tech News: 2024-26 ==

&lt;section begin=&quot;technews-2024-W26&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/26|Translations]] are available.

'''Recent changes'''
* Editors will notice that there have been some changes to the background color of text in the diff view, and the color of the byte-change numbers, last week. These changes are intended to make text more readable in both light mode and dark mode, and are part of a larger effort to increase accessibility. You can share your comments or questions [[mw:Talk:Reading/Web/Accessibility for reading|on the project talkpage]]. [https://phabricator.wikimedia.org/T361717]
* The text colors that are used for visited-links, hovered-links, and active-links, were also slightly changed last week to improve their accessibility in both light mode and dark mode. [https://phabricator.wikimedia.org/T366515]

'''Problems'''
* You can [[mw:Special:MyLanguage/Help:DiscussionTools#Talk pages permalinking|copy permanent links to talk page comments]] by clicking on a comment's timestamp. [[mw:Talk pages project/Permalinks|This feature]] did not always work when the topic title was very long and the link was used as a wikitext link. This has been fixed. Thanks to Lofhi for submitting the bug. [https://phabricator.wikimedia.org/T356196]

'''Changes later this week'''
* [[File:Octicons-sync.svg|12px|link=|alt=|Recurrent item]] The [[mw:MediaWiki 1.43/wmf.11|new version]] of MediaWiki will be on test wikis and MediaWiki.org from {{#time:j xg|2024-06-25|en}}. It will be on non-Wikipedia wikis and some Wikipedias from {{#time:j xg|2024-06-26|en}}. It will be on all wikis from {{#time:j xg|2024-06-27|en}} ([[mw:MediaWiki 1.43/Roadmap|calendar]]). [https://wikitech.wikimedia.org/wiki/Deployments/Train][https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]
* Starting 26 June, all talk pages messages' timestamps will become a link at English Wikipedia, making this feature available for you to use at all wikis. This link is a permanent link to the comment. It allows users to find the comment they were linked to, even if this comment has since been moved elsewhere. You can read more about this feature [[DiffBlog:/2024/01/29/talk-page-permalinks-dont-lose-your-threads/|on Diff]] or [[mw:Special:MyLanguage/Help:DiscussionTools#Talk pages permalinking|on Mediawiki.org]]. [https://phabricator.wikimedia.org/T365974]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/26|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W26&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:33, 24 June 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=26989424 --&gt;

== Wikipedia translation of the week: 2024-27 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Roller printing on textiles]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Silverstudio.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Roller printing''' on fabrics is a textile printing process patented by Thomas Bell of Scotland in 1783 in an attempt to reduce the cost of the earlier copperplate printing. This method was used in Lancashire fabric mills to produce cotton dress fabrics from the 1790s, most often reproducing small monochrome patterns characterized by striped motifs and tiny dotted patterns called &quot;machine grounds&quot;. Improvements in the technology resulted in more elaborate roller prints in bright, rich colours from the 1820s; Turkey red and chrome yellow were particularly popular. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:44, 1 July 2024 (UTC)''
&lt;/div&gt;
&lt;/div&gt;
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27031540 --&gt;

== Tech News: 2024-27 ==

&lt;section begin=&quot;technews-2024-W27&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/27|Translations]] are available.

'''Recent changes'''
* Over the next three weeks, dark mode will become available for all users, both logged-in and logged-out, starting with the mobile web version. This fulfils one of the [[m:Special:MyLanguage/Community_Wishlist_Survey_2023/Reading/Dark_mode|top-requested community wishes]], and improves low-contrast reading and usage in low-light settings. As part of these changes, dark mode will also work on User-pages and Portals. There is more information in [[mw:Special:MyLanguage/Reading/Web/Accessibility_for_reading/Updates#June_2024:_Typography_and_dark_mode_deployments,_new_global_preferences|the latest Web team update]]. [https://phabricator.wikimedia.org/T366364]
* Logged-in users can now set [[m:Special:GlobalPreferences#mw-prefsection-rendering-skin-skin-prefs|global preferences for the text-size and dark-mode]], thanks to a combined effort across Foundation teams. This allows Wikimedians using multiple wikis to set up a consistent reading experience easily, for example by switching between light and dark mode only once for all wikis. [https://phabricator.wikimedia.org/T341278] 
* If you use a very old web browser some features might not work on the Wikimedia wikis. This affects Internet Explorer 11 and versions of Chrome, Firefox and Safari older than 2016. This change makes it possible to use new [[d:Q46441|CSS]] features and to send less code to all readers. [https://phabricator.wikimedia.org/T288287][https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:How_to_make_a_MediaWiki_skin#Using_CSS_variables_for_supporting_different_themes_e.g._dark_mode]
* Wikipedia Admins can customize local wiki configuration options easily using [[mw:Special:MyLanguage/Community Configuration|Community Configuration]]. Community Configuration was created to allow communities to customize how some features work, because each language wiki has unique needs. At the moment, admins can configure [[mw:Special:MyLanguage/Growth/Feature_summary|Growth features]] on their home wikis, in order to better recruit and retain new editors. More options will be provided in the coming months. [https://phabricator.wikimedia.org/T366458]
* Editors interested in language issues that are related to [[w:en:Unicode|Unicode standards]], can now discuss those topics at [[mw:Talk:WMF membership with Unicode Consortium|a new conversation space in MediaWiki.org]]. The Wikimedia Foundation is now a [[mw:Special:MyLanguage/WMF membership with Unicode Consortium|member of the Unicode Consortium]], and the coordination group can collaboratively review the issues discussed and, where appropriate, bring them to the attention of the Unicode Consortium.
* One new wiki has been created: a {{int:project-localized-name-group-wikipedia}} in [[d:Q2891049|Mandailing]] ([[w:btm:|&lt;code&gt;w:btm:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T368038] 

'''Problems'''
* Editors can once again click on links within the visual editor's citation-preview, thanks to a bug fix by the Editing Team. [https://phabricator.wikimedia.org/T368119]

'''Future changes'''
* Please [https://wikimediafoundation.limesurvey.net/758713?lang=en help us to improve Tech News by taking this short survey]. The goal is to better meet the needs of the various types of people who read Tech News. The survey will be open for 2 weeks. The survey is covered by [https://foundation.wikimedia.org/wiki/Legal:Tech_News_Survey_2024_Privacy_Statement this privacy statement]. Some translations are available.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/27|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W27&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:59, 1 July 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27038456 --&gt;

== Wikipedia translation of the week: 2024-28 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:simple:India naming dispute]]'''&lt;br /&gt; &lt;small&gt;''([[:ur:انڈیا نام کا تنازعہ]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''India naming dispute''' in 1947 refers to the argument over the use of the name India during and after the partition of British Raj, between the countries of Pakistan and the Republic of India. This dispute involved key figures such as Lord Mountbatten, the last Viceroy of British Raj, and Muhammad Ali Jinnah, the leader of the Muslim League and a founder of Pakistan. By 1947, the British Raj was going to be divided into two new nation states – Hindustan and Pakistan. Jinnah was initially convinced that Hindustan would not use the term India, since it lacked indigenous pedigree, etymologically and historically India meant the Indus Valley (modern-Pakistan). He also opposed the use of the name India as it would cause confusion regarding history. The disagreement had significant implications for national identity and international recognition. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:13, 8 July 2024 (UTC)''
&lt;/div&gt;
&lt;/div&gt;
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27031540 --&gt;

== Tech News: 2024-28 ==

&lt;section begin=&quot;technews-2024-W28&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/28|Translations]] are available.

'''Recent changes'''
* At the Wikimedia Foundation a new task force was formed to replace the disabled Graph with [[mw:Special:MyLanguage/Extension:Chart/Project|more secure, easy to use, and extensible Chart]]. You can [[mw:Special:MyLanguage/Newsletter:Chart Project|subscribe to the newsletter]] to get notified about new project updates and other news about Chart.
* The [[m:Special:MyLanguage/CampaignEvents|CampaignEvents]] extension is now available on Meta-wiki, Igbo Wikipedia, and Swahili Wikipedia, and can be requested on your wiki. This extension helps in managing and making events more visible, giving Event organizers the ability to use tools like the Event registration tool. To learn more about the deployment status and how to request this extension for your wiki, visit the [[m:Special:MyLanguage/CampaignEvents/Deployment_status|CampaignEvents page on Meta-wiki]]. 
* Editors using the iOS Wikipedia app who have more than 50 edits can now use the [[mw:Special:MyLanguage/Wikimedia Apps/iOS Suggested edits#Add an image|Add an Image]] feature. This feature presents opportunities for small but useful contributions to Wikipedia.
* Thank you to [[mw:MediaWiki Product Insights/Contributor retention and growth/Celebration|all of the authors]] who have contributed to MediaWiki Core. As a result of these contributions, the [[mw:MediaWiki Product Insights/Contributor retention and growth|percentage of authors contributing more than 5 patches has increased by 25% since last year]], which helps ensure the sustainability of the platform for the Wikimedia projects.

'''Problems'''
* A problem with the color of the talkpage tabs always showing as blue, even for non-existent pages which should have been red, affecting the Vector 2022 skin, [[phab:T367982|has been fixed]]. 

'''Future changes'''
* The Trust and Safety Product team wants to introduce [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|temporary accounts]] with as little disruption to tools and workflows as possible. Volunteer developers, including gadget and user-script maintainers, are kindly asked to update the code of their tools and features to handle temporary accounts. The team has [[mw:Trust and Safety Product/Temporary Accounts/For developers|created documentation]] explaining how to do the update. [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts/For developers/2024-04 CTA|Learn more]].

'''Tech News survey'''
* Please [https://wikimediafoundation.limesurvey.net/758713?lang=en help us to improve Tech News by taking this short survey]. The goal is to better meet the needs of the various types of people who read Tech News. The survey will be open for 1 more week. The survey is covered by [https://foundation.wikimedia.org/wiki/Legal:Tech_News_Survey_2024_Privacy_Statement this privacy statement]. Some translations are available.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/28|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W28&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:32, 8 July 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27080357 --&gt;

== Wikipedia translation of the week: 2024-29 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Adumu]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Maasai 2012 05 31 2782 (7522645058).jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Adumu''', is a type of dance that the Maasai people of Kenya and Tanzania practice. Young Maasai warriors generally perform the energetic and acrobatic dance at ceremonial occasions including weddings, religious rites, and other significant cultural events. The Adumu dance is characterized by a sequence of jumps performed by the dancers, who stand in a circle and alternately jump while keeping their bodies as straight and upright as possible. In addition to wearing vividly colored shúkàs (clothes) and beaded jewelry, the dancers are typically clad in traditional Maasai costume. Traditional Maasai songs and chants are also performed during the dance. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:15, 15 July 2024 (UTC)''
&lt;/div&gt;
&lt;/div&gt;
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27031540 --&gt;

== Tech News: 2024-29 ==

&lt;section begin=&quot;technews-2024-W29&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/29|Translations]] are available.

'''Tech News survey'''
* Please [https://wikimediafoundation.limesurvey.net/758713?lang=en help us to improve Tech News by taking this short survey]. The goal is to better meet the needs of the various types of people who read Tech News. The survey will be open for 3 more days. The survey is covered by [https://foundation.wikimedia.org/wiki/Legal:Tech_News_Survey_2024_Privacy_Statement this privacy statement]. Some translations are available.

'''Recent changes'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Wikimedia developers can now officially continue to use both [[mw:Special:MyLanguage/Gerrit|Gerrit]] and [[mw:Special:MyLanguage/GitLab|GitLab]], due to a June 24 decision by the Wikimedia Foundation to support software development on both platforms. Gerrit and GitLab are both code repositories used by developers to write, review, and deploy the software code that supports the MediaWiki software that the wiki projects are built on, as well as the tools used by editors to create and improve content. This decision will safeguard the productivity of our developers and prevent problems in code review from affecting our users. More details are available in the [[mw:GitLab/Migration status|Migration status]] page.
* The Wikimedia Foundation seeks applicants for the [[m:Special:MyLanguage/Product and Technology Advisory Council/Proposal|Product and Technology Advisory Council]] (PTAC). This group will bring technical contributors and Wikimedia Foundation together to co-define a more resilient, future-proof technological platform. Council members will evaluate and consult on the movement's product and technical activities, so that we develop multi-generational projects. We are looking for a range of technical contributors across the globe, from a variety of Wikimedia projects. [[m:Special:MyLanguage/Product and Technology Advisory Council/Proposal#Joining the PTAC as a technical volunteer|Please apply here by August 10]].
* Editors with rollback user-rights who use the Wikipedia App for Android can use the new [[mw:Special:MyLanguage/Wikimedia Apps/Team/Android/Anti Vandalism|Edit Patrol]] features. These features include a new feed of Recent Changes, related links such as Undo and Rollback, and the ability to create and save a personal library of user talk messages to use while patrolling. If your wiki wants to make these features available to users who do not have rollback rights but have reached a certain edit threshold, [[mw:Special:MyLanguage/Wikimedia Apps/Team/Android#Contact us|you can contact the team]]. You can [[diffblog:2024/07/10/ِaddressing-vandalism-with-a-tap-the-journey-of-introducing-the-patrolling-feature-in-the-mobile-app/|read more about this project on Diff blog]].
* Editors who have access to [[m:Special:MyLanguage/The_Wikipedia_Library|The Wikipedia Library]] can once again use non-open access content in SpringerLinks, after the Foundation [[phab:T368865|contacted]] them to restore access. You can read more about [[m:Tech/News/Recently_resolved_community_tasks|this and 21 other community-submitted tasks that were completed last week]]. 

'''Changes later this week'''
* This week, [[mw:Special:MyLanguage/Reading/Web/Accessibility for reading/Updates/2024-07 deployments|dark mode will be available on a number of Wikipedias]], both desktop and mobile, for logged-in and logged-out users. Interface admins and user script maintainers are encouraged to check gadgets and user scripts in the dark mode, to find any hard-coded colors and fix them. There are some [[mw:Special:MyLanguage/Recommendations for night mode compatibility on Wikimedia wikis|recommendations for dark mode compatibility]] to help.

'''Future changes'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Next week, functionaries, volunteers maintaining tools, and software development teams are invited to test the [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|temporary accounts]] feature on testwiki. Temporary accounts is a feature that will help improve privacy on the wikis. No further temporary account deployments are scheduled yet. Please [[mw:Talk:Trust and Safety Product/Temporary Accounts|share your opinions and questions on the project talk page]]. [https://phabricator.wikimedia.org/T348895]
* Editors who upload files cross-wiki, or teach other people how to do so, may wish to join a Wikimedia Commons discussion. The Commons community is discussing limiting who can upload files through the cross-wiki upload/Upload dialog feature to users auto-confirmed on Wikimedia Commons. This is due to the large amount of copyright violations uploaded this way. There is a short summary at [[c:Special:MyLanguage/Commons:Cross-wiki upload|Commons:Cross-wiki upload]] and [[c:Commons:Village pump/Proposals#Deactivate cross-wiki uploads for new users|discussion at Commons:Village Pump]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/29|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].'' You can also get other news from the [[m:Special:MyLanguage/Wikimedia Foundation Bulletin|Wikimedia Foundation Bulletin]].
&lt;/div&gt;&lt;section end=&quot;technews-2024-W29&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:31, 16 July 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27124561 --&gt;

== Wikipedia translation of the week: 2024-30 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Rathaus-Glockenspiel]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:2019-11-16, Glockenspiel, Neues Münchner Rathaus, IMG 7463 edit Christoph Braun.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Rathaus-Glockenspiel''' is a large mechanical clock located in Marienplatz Square, in the heart of Munich, Germany. Famous for its life-size characters, the clock twice daily re-enacts scenes from Munich's history. First is the story of the marriage of Duke Wilhelm V to Renata of Lorraine in 1568, followed by the story of the Schäfflerstanz, also known as the coopers' dance. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:56, 22 July 2024 (UTC)''
&lt;/div&gt;
&lt;/div&gt;
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27031540 --&gt;

== Tech News: 2024-30 ==

&lt;section begin=&quot;technews-2024-W30&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/30|Translations]] are available.

'''Feature News'''
* Stewards can now [[:m:Special:MyLanguage/Global_blocks|globally block]] accounts. Before [[phab:T17294|the change]] only IP addresses and IP ranges could be blocked globally. Global account blocks are useful when the blocked user should not be logged out. [[:m:Special:MyLanguage/Global_locks|Global locks]] (a similar tool logging the user out of their account) are unaffected by this change. The new global account block feature is related to the [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|Temporary Accounts]] project, which is a new type of user account that replaces IP addresses of unregistered editors that are no longer made public.
* Later this week, Wikimedia site users will notice that the Interface of [[mw:Special:MyLanguage/Extension:FlaggedRevs|FlaggedRevs]] (also known as &quot;Pending Changes&quot;) is improved and consistent with the rest of the MediaWiki interface and [[mw:Special:MyLanguage/Codex|Wikimedia's design system]]. The FlaggedRevs interface experience on mobile and [[mw:Special:MyLanguage/Skin:MinervaNeue|Minerva skin]] was inconsistent before it was fixed and ported to [[mw:Special:MyLanguage/Codex|Codex]] by the WMF Growth team and some volunteers. [https://phabricator.wikimedia.org/T191156]
*  Wikimedia site users can now submit account vanishing requests via [[m:Special:GlobalVanishRequest|GlobalVanishRequest]]. This feature is used when a contributor wishes to stop editing forever. It helps you hide your past association and edit to protect your privacy. Once processed, the account will be locked and renamed. [https://phabricator.wikimedia.org/T367329]
* Have you tried monitoring and addressing vandalism in Wikipedia using your phone? [https://diff.wikimedia.org/2024/07/10/%d9%90addressing-vandalism-with-a-tap-the-journey-of-introducing-the-patrolling-feature-in-the-mobile-app/ A Diff blog post on Patrolling features in the Mobile App] highlights some of the new capabilities of the feature, including swiping through a feed of recent changes and a personal library of user talk messages for use when patrolling from your phone. 
* Wikimedia contributors and GLAM (galleries, libraries, archives, and museums) organisations can now learn and measure the impact Wikimedia Commons is having towards creating quality encyclopedic content using the [https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/reference/commons.html Commons Impact Metrics] analytics dashboard. The dashboard offers organizations analytics on things like monthly edits in a category, the most viewed files, and which Wikimedia articles are using Commons images. As a result of these new data dumps, GLAM organisation can more reliably measure their return on investment for programs bringing content into the digital Commons. [https://diff.wikimedia.org/2024/07/19/commons-impact-metrics-now-available-via-data-dumps-and-api/]

'''Project Updates'''
*  Come share your ideas for improving the wikis on the newly reopened [[m:Special:MyLanguage/Community Wishlist|Community Wishlist]]. The Community Wishlist is Wikimedia’s forum for volunteers to share ideas (called wishes) to improve how the wikis work. The new version of the wishlist is always open, works with both wikitext and Visual Editor, and allows wishes in any language.

'''Learn more'''
* Have you ever wondered how Wikimedia software works across over 300 languages? This is 253 languages more than the Google Chrome interface, and it's no accident. The Language and Product Localization Team at the Wikimedia Foundation supports your work by adapting all the tools and interfaces in the MediaWiki software so that contributors in our movement who translate pages and strings can translate them and have the sites in all languages. Read more about the team and their upcoming work on [https://diff.wikimedia.org/2024/07/17/building-towards-a-robust-multilingual-knowledge-ecosystem-for-the-wikimedia-movement/ Diff]. 
* How can Wikimedia build innovative and experimental products while maintaining such heavily used websites? A recent [https://diff.wikimedia.org/2024/07/09/on-the-value-of-experimentation/ blog post] by WMF staff Johan Jönsson highlights the work of the [[m:Future Audiences#Objectives and Key Results|WMF Future Audience initiative]], where the goal is not to build polished products but test out new ideas, such as a [[m:Future_Audiences/Experiments: conversational/generative AI|ChatGPT plugin]] and [[m:Future_Audiences/Experiment:Add a Fact|Add a Fact]], to help take Wikimedia into the future. 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/30|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].'' You can also get other news from the [[m:Special:MyLanguage/Wikimedia Foundation Bulletin|Wikimedia Foundation Bulletin]].
&lt;/div&gt;&lt;section end=&quot;technews-2024-W30&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:05, 23 July 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27142915 --&gt;

== Wikipedia translation of the week: 2024-31 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Nederlandsche Cocaïnefabriek]]'''&lt;br /&gt; &lt;small&gt;''([[:es:Nederlandsche Cocaïnefabriek]])&amp;#32;([[:nl:Nederlandsche Cocaïnefabriek]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Nederlandsche Cocainefabriek Schinkelstraat Amsterdam architect HH Baanders 1902.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Nederlandsche Cocaïnefabriek''' (Dutch pronunciation: [ˈneːdərlɑntsə koːkaːˈinəfaːˌbrik]; English: Dutch Cocaine Factory) or NCF was an Amsterdam-based company producing cocaine for medical purposes in the 20th century. It imported its raw materials mainly from the Dutch East Indies and sold its products across Europe, making good profits especially in the early years of World War I. The NCF produced morphine, heroin and ephedrine as well. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:44, 29 July 2024 (UTC)''
&lt;/div&gt;
&lt;/div&gt;
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27150339 --&gt;

== Tech News: 2024-31 ==

&lt;section begin=&quot;technews-2024-W31&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/31|Translations]] are available.

'''Feature news'''
* Editors using the Visual Editor in languages that use non-Latin characters for numbers, such as Hindi, Manipuri and Eastern Arabic, may notice some changes in the formatting of reference numbers. This is a side effect of preparing a new sub-referencing feature, and will also allow fixing some general numbering issues in Visual Editor. If you notice any related problems on your wiki, please share details at the [[m:Talk:WMDE Technical Wishes/Sub-referencing|project talkpage]].

'''Bugs status'''
* Some logged-in editors were briefly unable to edit or load pages last week. [[phab:T370304|These errors]] were mainly due to the addition of new [[mw:Special:MyLanguage/Help:Extension:Linter|linter]] rules which led to caching problems. Fixes have been applied and investigations are continuing.
* Editors can use the [[mw:Special:MyLanguage/Trust and Safety Product/IP Info|IP Information tool]] to get information about IP addresses. This tool is available as a Beta Feature in your preferences. The tool was not available for a few days last week, but is now working again. Thank you to Shizhao for filing the bug report. You can read about that, and [[m:Tech/News/Recently resolved community tasks#2024-07-25|28 other community-submitted tasks]] that were resolved last week.

'''Project updates'''
* There are new features and improvements to Phabricator from the Release Engineering and Collaboration Services teams, and some volunteers, including: the search systems, the new task creation system, the login systems, the translation setup which has resulted in support for more languages (thanks to Pppery), and fixes for many edge-case errors. You can [[phab:phame/post/view/316/iterative_improvements/|read details about these and other improvements in this summary]].
* There is an [[mw:Special:MyLanguage/Extension:Chart/Project/Updates|update on the Charts project]]. The team has decided which visualization library to use, which chart types to start focusing on, and where to store chart definitions.
* One new wiki has been created: a {{int:project-localized-name-group-wikivoyage}} in [[d:Q9056|Czech]] ([[voy:cs:|&lt;code&gt;voy:cs:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T370905] 

'''Learn more'''
* There is a [[diffblog:2024/07/26/the-journey-to-open-our-first-data-center-in-south-america/|new Wikimedia Foundation data center]] in São Paulo, Brazil which helps to reduce load times.
* There is new [[diffblog:2024/07/22/the-perplexing-process-of-uploading-images-to-wikipedia/|user research]] on problems with the process of uploading images.
* Commons Impact Metrics are [[diffblog:2024/07/19/commons-impact-metrics-now-available-via-data-dumps-and-api/|now available]] via data dumps and API.
* The latest quarterly [[mw:Technical Community Newsletter/2024/July|Technical Community Newsletter]] is now available.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/31|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W31&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:11, 29 July 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27164109 --&gt;

== Wikipedia translation of the week: 2024-32 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Suffrage drama]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Pamphlet from NAWSA for women's suffrage plays, page 1.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Suffrage drama''' (also known as suffrage plays or suffrage theatre) is a form of dramatic literature that emerged during the British women's suffrage movement in the early twentieth century. Suffrage performances lasted approximately from 1907-1914. Many suffrage plays called for a predominant or all female cast. Suffrage plays served to reveal issues behind the suffrage movement. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:13, 5 August 2024 (UTC)''
&lt;/div&gt;
&lt;/div&gt;
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27150339 --&gt;

== Tech News: 2024-32 ==

&lt;section begin=&quot;technews-2024-W32&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/32|Translations]] are available.

'''Feature news'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Two new parser functions will be available this week: &lt;code&gt;&lt;nowiki&gt;{{&lt;/nowiki&gt;[[mw:Special:MyLanguage/Help:Magic_words#dir|#dir]]&lt;nowiki&gt;}}&lt;/nowiki&gt;&lt;/code&gt; and &lt;code&gt;&lt;nowiki&gt;{{&lt;/nowiki&gt;[[mw:Special:MyLanguage/Help:Magic_words#bcp47|#bcp47]]&lt;nowiki&gt;}}&lt;/nowiki&gt;&lt;/code&gt;. These will reduce the need for &lt;code&gt;Template:Dir&lt;/code&gt; and &lt;code&gt;Template:BCP47&lt;/code&gt; on Commons and allow us to [[phab:T343131|drop 100 million rows]] from the &quot;what links here&quot; database. Editors at any wiki that use these templates, can help by replacing the templates with these new functions. The templates at Commons will be updated during the Hackathon at Wikimania. [https://phabricator.wikimedia.org/T359761][https://phabricator.wikimedia.org/T366623]
* Communities can request the activation of the visual editor on entire namespaces where discussions sometimes happen (for instance ''Wikipedia:'' or ''Wikisource:'' namespaces) if they understand the [[mw:Special:MyLanguage/Help:VisualEditor/FAQ#WPNS|known limitations]]. For discussions, users can already use [[mw:Special:MyLanguage/Help:DiscussionTools|DiscussionTools]] in these namespaces.
* The tracking category &quot;Pages using Timeline&quot; has been renamed to &quot;Pages using the EasyTimeline extension&quot; [https://translatewiki.net/wiki/Special:Translations?message=MediaWiki%3ATimeline-tracking-category&amp;namespace=8 in TranslateWiki]. Wikis that have created the category locally should rename their local creation to match.

'''Project updates'''
* Editors who help to organize WikiProjects and similar on-wiki collaborations, are invited to share ideas and examples of successful collaborations with the Campaigns and Programs teams. You can fill out [[m:Special:MyLanguage/Campaigns/WikiProjects|a brief survey]] or share your thoughts [[m:Talk:Campaigns/WikiProjects|on the talkpage]]. The teams are particularly looking for details about successful collaborations on non-English wikis.
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] The new parser is being rolled out on {{int:project-localized-name-group-wikivoyage}} wikis over the next few months. The {{int:project-localized-name-enwikivoyage}} and {{int:project-localized-name-hewikivoyage}} were [[phab:T365367|switched]] to Parsoid last week. For more information, see [[mw:Parsoid/Parser_Unification|Parsoid/Parser Unification]].

'''Learn more'''
* There will be more than 200 sessions at Wikimania this week. Here is a summary of some of the [[diffblog:2024/08/05/interested-in-product-and-tech-here-are-some-wikimania-sessions-you-dont-want-to-miss/|key sessions related to the product and technology area]].
* The latest [[m:Special:MyLanguage/Wikimedia Foundation Bulletin/2024/07-02|Wikimedia Foundation Bulletin]] is available.
* The latest quarterly [[mw:Special:MyLanguage/Wikimedia Language and Product Localization/Newsletter/2024/July|Language and Internationalization newsletter]] is available. It includes: New design previews for Translatable pages; Updates about MinT for Wiki Readers; the release of Translation dumps; and more.
* The latest quarterly [[mw:Special:MyLanguage/Growth/Newsletters/31|Growth newsletter]] is available.
* The latest monthly [[mw:Special:MyLanguage/MediaWiki Product Insights/Reports/July 2024|MediaWiki Product Insights newsletter]] is available.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/32|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W32&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:44, 5 August 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27233905 --&gt;

== Wikipedia translation of the week: 2024-33 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Karatgurk]]'''&lt;br /&gt; &lt;small&gt;''([[:it:Karatgurk]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
In the Australian Aboriginal mythology of the Aboriginal people of south-eastern Australian state of Victoria, the '''Karatgurk''' were seven sisters who represented the constellation known in western astronomy as the Pleiades. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] --[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:13, 12 August 2024 (UTC)''
&lt;/div&gt;
&lt;/div&gt;
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27264174 --&gt;

== Tech News: 2024-33 ==

&lt;section begin=&quot;technews-2024-W33&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/33|Translations]] are available.

'''Feature news'''
* [[mw:Special:MyLanguage/Extension:AbuseFilter|AbuseFilter]] editors and maintainers can now [[mw:Special:MyLanguage/Extension:AbuseFilter/Actions#Show a CAPTCHA|make a CAPTCHA show if a filter matches an edit]]. This allows communities to quickly respond to spamming by automated bots. [https://phabricator.wikimedia.org/T20110]
* [[m:Special:MyLanguage/Stewards|Stewards]] can now specify if global blocks should prevent account creation. Before [[phab:T17273|this change]] by the [[mw:Special:MyLanguage/Trust and Safety Product|Trust and Safety Product]] Team, all global blocks would prevent account creation. This will allow stewards to reduce the unintended side-effects of global blocks on IP addresses.

'''Project updates'''
* [[wikitech:Help talk:Toolforge/Toolforge standards committee#August_2024_committee_nominations|Nominations are open on Wikitech]] for new members to refresh the [[wikitech:Help:Toolforge/Toolforge standards committee|Toolforge standards committee]]. The committee oversees the Toolforge [[wikitech:Help:Toolforge/Right to fork policy|Right to fork policy]] and [[wikitech:Help:Toolforge/Abandoned tool policy|Abandoned tool policy]] among other duties. Nominations will remain open until at least 2024-08-26.
* One new wiki has been created: a {{int:project-localized-name-group-wikipedia}} in [[d:Q2880037|West Coast Bajau]] ([[w:bdr:|&lt;code&gt;w:bdr:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T371757]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/33|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W33&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:22, 12 August 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27253654 --&gt;

== Wikipedia translation of the week: 2024-34 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:B1 (classification)]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''B1''' is a medical-based Paralympic classification for blind sport. Athletes in this classification are totally or almost totally blind. It is used by a number of blind sports including blind tennis, para-alpine skiing, para-Nordic skiing, blind cricket, blind golf, five-a-side football, goalball and judo. Some other sports, including adaptive rowing, athletics and swimming, have equivalents to this class.

The B1 classification was first created by the IBSA in the 1970s, and has largely remained unchanged since despite an effort by the International Paralympic Committee (IPC) to move towards a more functional and evidence-based classification system. Classification is often handled on the international level by the International Blind Sports Federation (IBSA) but it sometimes handled by national sport federations. There are exceptions for sports like athletics and cycling, where classification is handled by their own governing bodies.

Equipment utilized by competitors in this class may differ from sport to sport, and may include sighted guides, guide rails, beeping balls and clapsticks. There may be some modifications related to equipment and rules to specifically address needs of competitors in this class to allow them to compete in specific sports. Some sports specifically do not allow a guide, whereas cycling and skiing require one. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:56, 19 August 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27278917 --&gt;

== Tech News: 2024-34 ==

&lt;section begin=&quot;technews-2024-W34&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/34|Translations]] are available.

'''Feature news'''
* Editors who want to re-use references but with different details such as page numbers, will be able to do so by the end of 2024, using a new [[m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing#Sub-referencing in a nutshell|sub-referencing]] feature. You can read more [[m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing|about the project]] and [[m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing#Test|how to test the prototype]].
* Editors using tracking categories to identify which pages use specific extensions may notice that six of the categories have been renamed to make them more easily understood and consistent. These categories are automatically added to pages that use specialized MediaWiki extensions. The affected names are for: [https://translatewiki.net/wiki/Special:Translations?message=MediaWiki%3Aintersection-category&amp;namespace=8 DynamicPageList], [https://translatewiki.net/wiki/Special:Translations?message=MediaWiki%3Akartographer-tracking-category&amp;namespace=8 Kartographer], [https://translatewiki.net/wiki/Special:Translations?message=MediaWiki%3Aphonos-tracking-category&amp;namespace=8 Phonos], [https://translatewiki.net/wiki/Special:Translations?message=MediaWiki%3Arss-tracking-category&amp;namespace=8 RSS], [https://translatewiki.net/wiki/Special:Translations?message=MediaWiki%3Ascore-use-category&amp;namespace=8 Score], [https://translatewiki.net/wiki/Special:Translations?message=MediaWiki%3Awikihiero-usage-tracking-category&amp;namespace=8 WikiHiero]. Wikis that have created the category locally should rename their local creation to match. Thanks to Pppery for these improvements. [https://phabricator.wikimedia.org/T347324]
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Technical volunteers who edit modules and want to get a list of the categories used on a page, can now do so using the &lt;code&gt;&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;categories&lt;/bdi&gt;&lt;/code&gt; property of &lt;code&gt;&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;[[mediawikiwiki:Special:MyLanguage/Extension:Scribunto/Lua reference manual#Title objects|mw.title objects]]&lt;/bdi&gt;&lt;/code&gt;. This enables wikis to configure workflows such as category-specific edit notices. Thanks to SD001 for these improvements. [https://phabricator.wikimedia.org/T50175][https://phabricator.wikimedia.org/T85372]

'''Bugs status'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Your help is needed to check if any pages need to be moved or deleted. A maintenance script was run to clean up unreachable pages (due to Unicode issues or introduction of new namespaces/namespace aliases). The script tried to find appropriate names for the pages (e.g. by following the Unicode changes or by moving pages whose titles on Wikipedia start with &lt;code&gt;Talk:WP:&lt;/code&gt; so that their titles start with &lt;code&gt;Wikipedia talk:&lt;/code&gt;), but it may have failed for some pages, and moved them to &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;[[Special:PrefixIndex/T195546/]]&lt;/bdi&gt; instead. Your community should check if any pages are listed there, and move them to the correct titles, or delete them if they are no longer needed. A full log (including pages for which appropriate names could be found) is available in [[phab:P67388]].
* Editors who volunteer as [[mw:Special:MyLanguage/Help:Growth/Mentorship|mentors]] to newcomers on their wiki are once again able to access lists of potential mentees who they can connect with to offer help and guidance. This functionality was restored thanks to [[phab:T372164|a bug fix]]. Thank you to Mbch331 for filing the bug report. You can read about that, and 18 other community-submitted tasks that were [[m:Tech/News/Recently resolved community tasks|resolved last week]].

'''Project updates'''
* The application deadline for the [[m:Special:MyLanguage/Product and Technology Advisory Council/Proposal|Product &amp; Technology Advisory Council]] (PTAC) has been extended to September 16. Members will help by providing advice to Foundation Product and Technology leadership on short and long term plans, on complex strategic problems, and help to get feedback from more contributors and technical communities. Selected members should expect to spend roughly 5 hours per month for the Council, during the one year pilot. Please consider applying, and spread the word to volunteers you think would make a positive contribution to the committee.

'''Learn more'''
* The [[m:Special:MyLanguage/Coolest Tool Award#2024 Winners|2024 Coolest Tool Awards]] were awarded at Wikimania, in seven categories. For example, one award went to the ISA Tool, used for adding structured data to files on Commons, which was recently improved during the [[m:Event:Wiki Mentor Africa ISA Hackathon 2024|Wiki Mentor Africa Hackathon]]. You can see video demonstrations of each tool at the awards page. Congratulations to this year's recipients, and thank you to all tool creators and maintainers.
* The latest [[m:Special:MyLanguage/Wikimedia Foundation Bulletin/2024/08-01|Wikimedia Foundation Bulletin]] is available, and includes some highlights from Wikimania, an upcoming Language community meeting, and other news from the movement.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/34|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W34&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:54, 20 August 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27307284 --&gt;

== Wikipedia translation of the week: 2024-35 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Erzi (village)]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Caucasus, Ingushetia, Ингушские боевые и смотровые башни, горы Кавказа.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Erzi''' (Russian: Эрзи; Ingush: Аьрзи, romanized: Ärzi, lit. 'Eagle') is a medieval village (aul) in the Dzheyrakhsky District of Ingushetia. It is part of the rural settlement (administrative center) of Olgeti. The entire territory of the settlement is included in the Dzheyrakh-Assa State Historical-Architectural and Natural Museum-Reserve and is under state protection. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 03:19, 26 August 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27345183 --&gt;

== Tech News: 2024-35 ==

&lt;section begin=&quot;technews-2024-W35&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/35|Translations]] are available.

'''Feature news'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Administrators can now test the [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|temporary accounts]] feature on test2wiki. This was done to allow cross-wiki testing of temporary accounts, for when temporary accounts switch between projects. The feature was enabled on testwiki a few weeks ago. No further temporary account deployments are scheduled yet. Temporary Accounts is a project to create a new type of user account that replaces IP addresses of unregistered editors which are no longer made public. Please [[mw:Talk:Trust and Safety Product/Temporary Accounts|share your opinions and questions on the project talk page]].
* Later this week, editors at wikis that use [[mw:Special:MyLanguage/Extension:FlaggedRevs|FlaggedRevs]] (also known as &quot;Pending Changes&quot;) may notice that the indicators at the top of articles have changed. This change makes the system more consistent with the rest of the MediaWiki interface. [https://phabricator.wikimedia.org/T191156]

'''Bugs status'''
* Editors who use the 2010 wikitext editor, and use the Character Insert buttons, will [[phab:T361465|no longer]] experience problems with the buttons adding content into the edit-summary instead of the edit-window. You can read more about that, and 26 other community-submitted tasks that were [[m:Tech/News/Recently resolved community tasks|resolved last week]].

'''Project updates'''
* [[File:Octicons-gift.svg|12px|link=|class=skin-invert|Wishlist item]] Please review and vote on [[m:Special:MyLanguage/Community Wishlist/Focus areas|Focus Areas]], which are groups of wishes that share a problem. Focus Areas were created for the newly reopened Community Wishlist, which is now open year-round for submissions. The first batch of focus areas are specific to moderator workflows, around welcoming newcomers, minimizing repetitive tasks, and prioritizing tasks. Once volunteers have reviewed and voted on focus areas, the Foundation will then review and select focus areas for prioritization.
* Do you have a project and are willing to provide a three (3) month mentorship for an intern? [[mw:Special:MyLanguage/Outreachy|Outreachy]] is a twice a year program for people to participate in a paid internship that will start in December 2024 and end in early March 2025, and they need mentors and projects to work on. Projects can be focused on coding or non-coding (design, documentation, translation, research). See the Outreachy page for more details, and a list of past projects since 2013.

'''Learn more'''
* If you're curious about the product and technology improvements made by the Wikimedia Foundation last year, read [[diffblog:2024/08/21/wikimedia-foundation-product-technology-improving-the-user-experience/|this recent highlights summary on Diff]].
* To learn more about the technology behind the Wikimedia projects, you can now watch sessions from the technology track at Wikimania 2024 on Commons. This week, check out:
** [[c:File:Wikimania 2024 - Ohrid - Day 2 - Community Configuration - Shaping On-Wiki Functionality Together.webm|Community Configuration - Shaping On-Wiki Functionality Together]] (55 mins) - about the [[mw:Special:MyLanguage/Community Configuration|Community Configuration]] project.
** [[c:File:Wikimania 2024 - Belgrade - Day 1 - Future of MediaWiki. A sustainable platform to support a collaborative user base and billions of page views.webm|Future of MediaWiki. A sustainable platform to support a collaborative user base and billions of page views]] (30 mins) - an overview for both technical and non technical audiences, covering some of the challenges and open questions, related to the [[mw:MediaWiki Product Insights|platform evolution, stewardship and developer experiences]] research.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/35|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W35&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:34, 26 August 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27341211 --&gt;

== Tech News: 2024-36 ==

&lt;section begin=&quot;technews-2024-W36&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/36|Translations]] are available.

'''Weekly highlight'''
* Editors and volunteer developers interested in data visualisation can now test the new software for charts. Its early version is available on beta Commons and beta Wikipedia. This is an important milestone before making charts available on regular wikis. You can [[mw:Special:MyLanguage/Extension:Chart/Project/Updates|read more about this project update]] and help to test the charts.

'''Feature news'''
* Editors who use the [[{{#special:Unusedtemplates}}]] page can now filter out pages which are expected to be there permanently, such as sandboxes, test-cases, and templates that are always substituted. Editors can add the new magic word [[mw:Special:MyLanguage/Help:Magic words#EXPECTUNUSEDTEMPLATE|&lt;code dir=&quot;ltr&quot;&gt;&lt;nowiki&gt;__EXPECTUNUSEDTEMPLATE__&lt;/nowiki&gt;&lt;/code&gt;]] to a template page to hide it from the listing. Thanks to Sophivorus and DannyS712 for these improvements. [https://phabricator.wikimedia.org/T184633]
* Editors who use the New Topic tool on discussion pages, will [[phab:T334163|now be reminded]] to add a section header, which should help reduce the quantity of newcomers who add sections without a header. You can read more about that, and {{formatnum:28}} other community-submitted tasks that were [[m:Tech/News/Recently resolved community tasks|resolved last week]].
* Last week, some Toolforge tools had occasional connection problems. The cause is still being investigated, but the problems have been resolved for now. [https://phabricator.wikimedia.org/T373243]
* Translation administrators at multilingual wikis, when editing multiple translation units, can now easily mark which changes require updates to the translation. This is possible with the [[phab:T298852#10087288|new dropdown menu]].

'''Project updates'''
* A new draft text of a policy discussing the use of Wikimedia's APIs [[m:Special:MyLanguage/API Policy Update 2024|has been published on Meta-Wiki]]. The draft text does not reflect a change in policy around the APIs; instead, it is an attempt to codify existing API rules. Comments, questions, and suggestions are welcome on [[m:Talk:API Policy Update 2024|the proposed update’s talk page]] until September 13 or until those discussions have concluded.

'''Learn more'''
* To learn more about the technology behind the Wikimedia projects, you can now watch sessions from the technology track at Wikimania 2024 on Commons. This week, check out:
** [[c:File:Wikimania 2024 - Ohrid - Day 2 - Charts, the successor of Graphs - A secure and extensible tool for data visualization.webm|Charts, the successor of Graphs - A secure and extensible tool for data visualization]] (25 mins) – about the above-mentioned Charts project.
** [[c:File:Wikimania 2024 - Ohrid - Day 3 - State of Language Technology and Onboarding at Wikimedia.webm|State of Language Technology and Onboarding at Wikimedia]] (90 mins) – about some of the language tools that support Wikimedia sites, such as [[mw:Special:MyLanguage/Content translation|Content]]/[[mw:Special:MyLanguage/Content translation/Section translation|Section Translation]], [[mw:Special:MyLanguage/MinT|MinT]], and LanguageConverter; also the current state and future of languages onboarding. [https://phabricator.wikimedia.org/T368772]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/36|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W36&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:08, 3 September 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27390268 --&gt;

== Wikipedia translation of the week: 2024-37 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Cappadocian calendar]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Cappadocian calendar''' was a solar calendar that was derived from the Persian Zoroastrian calendar. It is named after the historic region Cappadocia in present-day Turkey, where it was used. The calendar, which had 12 months of 30 days each and five epagomenal days, originated between 550 and 330 BC, when Cappadocia was part of the Persian Achaemenid Empire. The Cappadocian calendar was identical to the Zoroastrian calendar; this can be seen in its structure, in the Avestan names and in the order of the months. The Cappadocian calendar reflects the Iranian cultural influence in the region. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:42, 9 September 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27357319 --&gt;

== Tech News: 2024-37 ==

&lt;section begin=&quot;technews-2024-W37&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/37|Translations]] are available.

'''Feature news'''
* Starting this week, the standard [[mw:Special:MyLanguage/Extension:CodeMirror|syntax highlighter]] will receive new colors that make them compatible in dark mode. This is the first of many changes to come as part of a major upgrade to syntax highlighting. You can learn more about what's to come on the [[mw:Special:MyLanguage/Help:Extension:CodeMirror|help page]]. [https://phabricator.wikimedia.org/T365311][https://phabricator.wikimedia.org/T259059]
* Editors of wikis using Wikidata will now be notified of only relevant Wikidata changes in their watchlist. This is because the Lua functions &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;entity:getSitelink()&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;mw.wikibase.getSitelink(qid)&lt;/code&gt;&lt;/bdi&gt; will have their logic unified for tracking different aspects of sitelinks to reduce junk notifications from [[m:Wikidata For Wikimedia Projects/Projects/Watchlist Wikidata Sitelinks Tracking|inconsistent sitelinks tracking]]. [https://phabricator.wikimedia.org/T295356]

'''Project updates'''
*  Users of all Wikis will have access to Wikimedia sites as read-only for a few minutes on September 25, starting at 15:00 UTC. This is a planned datacenter switchover for maintenance purposes. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [https://phabricator.wikimedia.org/T370962]
* Contributors of [[phab:T363538#10123348|11 Wikipedias]], including English will have a new &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;MOS&lt;/code&gt;&lt;/bdi&gt; namespace added to their Wikipedias. This improvement ensures that links beginning with &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;MOS:&lt;/code&gt;&lt;/bdi&gt; (usually shortcuts to the [[w:en:Wikipedia:Manual of Style|Manual of Style]]) are not broken by [[w:en:Mooré|Mooré]] Wikipedia (language code &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;mos&lt;/code&gt;&lt;/bdi&gt;). [https://phabricator.wikimedia.org/T363538]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/37|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W37&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 18:53, 9 September 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27424457 --&gt;

== Tech News: 2024-38 ==

&lt;section begin=&quot;technews-2024-W38&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/38|Translations]] are available.

'''Improvements and Maintenance'''
* [[File:Octicons-gift.svg|12px|link=|class=skin-invert|Wishlist item]] Editors interested in templates can help by reading the latest Wishlist focus area, [[m:Special:MyLanguage/Community Wishlist/Focus areas/Template recall and discovery|Template recall and discovery]], and share your feedback on the talkpage. This input helps the Community Tech team to decide the right technical approach to build. Everyone is also encouraged to continue adding [[m:Special:MyLanguage/Community Wishlist|new wishes]].
* The new automated [[{{#special:NamespaceInfo}}]] page helps editors understand which [[mw:Special:MyLanguage/Help:Namespaces|namespaces]] exist on each wiki, and some details about how they are configured. Thanks to DannyS712 for these improvements. [https://phabricator.wikimedia.org/T263513]
* [[mw:Special:MyLanguage/Help:Edit check#Reference check|References Check]] is a feature that encourages editors to add a citation when they add a new paragraph to a Wikipedia article. For a short time, the corresponding tag &quot;Edit Check (references) activated&quot; was erroneously being applied to some edits outside of the main namespace. This has been fixed. [https://phabricator.wikimedia.org/T373692]
* It is now possible for a wiki community to change the order in which a page’s categories are displayed on their wiki. By default, categories are displayed in the order they appear in the wikitext. Now, wikis with a consensus to do so can [[m:Special:MyLanguage/Requesting wiki configuration changes|request]] a configuration change to display them in alphabetical order. [https://phabricator.wikimedia.org/T373480]
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Tool authors can now access ToolsDB's [[wikitech:Portal:Data Services#ToolsDB|public databases]] from both [[m:Special:MyLanguage/Research:Quarry|Quarry]] and [[wikitech:Superset|Superset]]. Those databases have always been accessible to every [[wikitech:Portal:Toolforge|Toolforge]] user, but they are now more broadly accessible, as Quarry can be accessed by anyone with a Wikimedia account. In addition, Quarry's internal database can now be [[m:Special:MyLanguage/Research:Quarry#Querying Quarry's own database|queried from Quarry itself]]. This database contains information about all queries that are being run and starred by users in Quarry. This information was already public through the web interface, but you can now query it using SQL. You can read more about that, and {{formatnum:20}} other community-submitted tasks that were [[m:Tech/News/Recently resolved community tasks|resolved last week]].
* Any pages or tools that still use the very old CSS classes &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;mw-message-box&lt;/code&gt;&lt;/bdi&gt; need to be updated. These old classes will be removed next week or soon afterwards. Editors can use a [https://global-search.toolforge.org/?q=mw-message-box&amp;regex=1&amp;namespaces=&amp;title= global-search] to determine what needs to be changed. It is possible to use the newer &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;cdx-message&lt;/code&gt;&lt;/bdi&gt; group of classes as a replacement (see [https://doc.wikimedia.org/codex/latest/components/demos/message.html#css-only-version the relevant Codex documentation], and [https://meta.wikimedia.org/w/index.php?title=Tech/Header&amp;diff=prev&amp;oldid=27449042 an example update]), but using locally defined onwiki classes would be best. [https://phabricator.wikimedia.org/T374499]

'''Technical project updates'''
* Next week, all Wikimedia wikis will be read-only for a few minutes. This will start on September 25 at [https://zonestamp.toolforge.org/1727276400 15:00 UTC]. This is a planned datacenter switchover for maintenance purposes. [[m:Special:MyLanguage/Tech/Server switch|This maintenance process also targets other services.]] The previous switchover took 3 minutes, and the Site Reliability Engineering teams use many tools to make sure that this essential maintenance work happens as quickly as possible. [https://phabricator.wikimedia.org/T370962]

'''Tech in depth'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] The latest monthly [[mw:Special:MyLanguage/MediaWiki Product Insights/Reports/August 2024|MediaWiki Product Insights newsletter]] is available. This edition includes details about: research about [[mw:Special:MyLanguage/Manual:Hooks|hook]] handlers to help simplify development, research about performance improvements, work to improve the REST API for end-users, and more.
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] To learn more about the technology behind the Wikimedia projects, you can now watch sessions from the technology track at Wikimania 2024 on Commons. This week, check out: 
** [[c:File:Wikimania 2024 - Auditorium Kyiv - Day 4 - Hackathon Showcase.webm|Hackathon Showcase]] (45 mins) - 19 short presentations by some of the Hackathon participants, describing some of the projects they worked on, such as automated testing of maintenance scripts, a video-cutting command line tool, and interface improvements for various tools. There are [[phab:T369234|more details and links available]] in the Phabricator task.
** [[c:File:Co-Creating a Sustainable Future for the Toolforge Ecosystem.webm|Co-Creating a Sustainable Future for the Toolforge Ecosystem]] (40 mins) - a roundtable discussion for tool-maintainers, users, and supporters of Toolforge about how to make the platform sustainable and how to evaluate the tools available there.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/38|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W38&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:03, 17 September 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27460876 --&gt;

== Wikipedia translation of the week: 2024-39 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Independence Day (Albania)]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Independence Day''' (Albanian: Dita e Pavarësisë) is a public holiday in Albania observed on 28 November. It commemorates the Albanian Declaration of Independence (from the Ottoman Empire), which was ratified by the All-Albanian Congress on 28 November 1912, establishing the state of Albania. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 00:29, 23 September 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27456350 --&gt;

== Tech News: 2024-39 ==

&lt;section begin=&quot;technews-2024-W39&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/39|Translations]] are available.

'''Weekly highlight'''
* All wikis will be [[m:Special:MyLanguage/Tech/Server switch|read-only]] for a few minutes on Wednesday September 25 at [https://zonestamp.toolforge.org/1727276400 15:00 UTC]. Reading the wikis will not be interrupted, but editing will be paused. These twice-yearly processes allow WMF's site reliability engineering teams to remain prepared to keep the wikis functioning even in the event of a major interruption to one of our data centers.

'''Updates for editors'''
[[File:Add alt text from a halfsheet, with the article behind.png|thumb|A screenshot of the interface for the Alt Text suggested-edit feature]]
* Editors who use the iOS Wikipedia app in Spanish, Portuguese, French, or Chinese, may see the [[mw:Special:MyLanguage/Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment|Alt Text suggested-edit experiment]] after editing an article, or completing a suggested edit using &quot;[[mw:Special:MyLanguage/Wikimedia Apps/iOS Suggested edits project#Hypothesis 2 Add an Image Suggested Edit|Add an image]]&quot;. Alt-text helps people with visual impairments to read Wikipedia articles. The team aims to learn if adding alt-text to images is a task that editors can be successful with. Please share any feedback on [[mw:Talk:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment|the discussion page]].
* The Codex color palette has been updated with new and revised colors for the MediaWiki user interfaces. The [[mw:Special:MyLanguage/Design System Team/Color/Design documentation#Updates|most noticeable changes]] for editors include updates for: dark mode colors for Links and for quiet Buttons (progressive and destructive), visited Link colors for both light and dark modes, and background colors for system-messages in both light and dark modes.
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] It is now possible to include clickable wikilinks and external links inside code blocks. This includes links that are used within &lt;code&gt;&lt;nowiki&gt;&lt;syntaxhighlight&gt;&lt;/nowiki&gt;&lt;/code&gt; tags and on code pages (JavaScript, CSS, Scribunto and Sanitized CSS). Uses of template syntax &lt;code&gt;&lt;nowiki&gt;{{…}}&lt;/nowiki&gt;&lt;/code&gt; are also linked to the template page. Thanks to SD0001 for these improvements. [https://phabricator.wikimedia.org/T368166]
* Two bugs were fixed in the [[m:Special:MyLanguage/Account vanishing|GlobalVanishRequest]] system by improving the logging and by removing an incorrect placeholder message. [https://phabricator.wikimedia.org/T370595][https://phabricator.wikimedia.org/T372223]
* View all {{formatnum:25}} community-submitted {{PLURAL:25|task|tasks}} that were [[m:Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] From [[m:Special:MyLanguage/Wikimedia Enterprise|Wikimedia Enterprise]]: 
** The API now enables 5,000 on-demand API requests per month and twice-monthly HTML snapshots freely (gratis and libre). More information on the updates and also improvements to the software development kits (SDK) are explained on [https://enterprise.wikimedia.com/blog/enhanced-free-api/ the project's blog post]. While Wikimedia Enterprise APIs are designed for high-volume commercial reusers, this change enables many more community use-cases to be built on the service too.
** The Snapshot API (html dumps) have added beta Structured Contents endpoints ([https://enterprise.wikimedia.com/blog/structured-contents-snapshot-api/ blog post on that]) as well as released two beta datasets (English and French Wikipedia) from that endpoint to Hugging Face for public use and feedback ([https://enterprise.wikimedia.com/blog/hugging-face-dataset/ blog post on that]). These pre-parsed data sets enable new options for researchers, developers, and data scientists to use and study the content.

'''In depth'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] The Wikidata Query Service (WDQS) is used to get answers to questions using the Wikidata data set. As Wikidata grows, we had to make a major architectural change so that WDQS could remain performant. As part of the [[d:Special:MyLanguage/Wikidata:SPARQL query service/WDQS graph split|WDQS Graph Split project]], we have new SPARQL endpoints available for serving the &quot;[https://query-scholarly.wikidata.org scholarly]&quot; and &quot;[https://query-main.wikidata.org main]&quot; subgraphs of Wikidata. The [http://query.wikidata.org query.wikidata.org endpoint] will continue to serve the full Wikidata graph until March 2025. After this date, it will only serve the main graph. For more information, please see [[d:Special:MyLanguage/Wikidata:SPARQL query service/WDQS backend update/September 2024 scaling update|the announcement on Wikidata]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/39|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W39&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:37, 23 September 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27493779 --&gt;

== Wikipedia translation of the week: 2024-40 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Wildlife of Bahrain]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Birds in Al-Areen Wildlife Park.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The wildlife of the archipelago of Bahrain, is more varied than might be expected of this small group of islands in the Persian Gulf. Apart from a strip of the north and west of the main island, where crops are grown with irrigation, the land is arid. With a very hot dry summer, a mild winter, and brackish groundwater, the plants need adaptations in order to survive. Nevertheless, 196 species of higher plant have been recorded here, as well as about seventeen species of terrestrial mammals, many birds and reptiles, and many migratory birds visit the islands in autumn and spring. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:57, 30 September 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27456350 --&gt;

== Tech News: 2024-40 ==

&lt;section begin=&quot;technews-2024-W40&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/40|Translations]] are available.

'''Updates for editors'''
* Readers of [[phab:T375401|42 more wikis]] can now use Dark Mode. If the option is not yet available for logged-out users of your wiki, this is likely because many templates do not yet display well in Dark Mode. Please use the [https://night-mode-checker.wmcloud.org/ night-mode-checker tool] if you are interested in helping to reduce the number of issues. The [[mw:Special:MyLanguage/Recommendations for night mode compatibility on Wikimedia wikis|recommendations page]] provides guidance on this. Dark Mode is enabled on additional wikis once per month.
* Editors using the 2010 wikitext editor as their default can access features from the 2017 wikitext editor by adding &lt;code dir=ltr&gt;?veaction=editsource&lt;/code&gt; to the URL. If you would like to enable the 2017 wikitext editor as your default, it can be set in [[Special:Preferences#mw-input-wpvisualeditor-newwikitext|your preferences]]. [https://phabricator.wikimedia.org/T239796]
* For logged-out readers using the Vector 2022 skin, the &quot;donate&quot; link has been moved from a collapsible menu next to the content area into a more prominent top menu, next to &quot;Create an account&quot;. This restores the link to the level of prominence it had in the Vector 2010 skin. [[mw:Readers/2024 Reader and Donor Experiences#Donor Experiences (Key Result WE 3.2 and the related hypotheses)|Learn more]] about the changes related to donor experiences. [https://phabricator.wikimedia.org/T373585]
* The CampaignEvents extension provides tools for organizers to more easily manage events, communicate with participants, and promote their events on the wikis. The extension has been [[m:Special:MyLanguage/CampaignEvents/Deployment status|enabled]] on Arabic Wikipedia, Igbo Wikipedia, Swahili Wikipedia, and Meta-Wiki. [[w:zh:Wikipedia:互助客栈/其他#引進CampaignEvents擴充功能|Chinese Wikipedia has decided]] to enable the extension, and discussions on the extension are in progress [[w:es:Wikipedia:Votaciones/2024/Sobre la política de Organizadores de Eventos|on Spanish Wikipedia]] and [[d:Wikidata:Project chat#Enabling the CampaignEvents Extention on Wikidata|on Wikidata]]. To learn how to enable the extension on your wiki, you can visit [[m:Special:MyLanguage/CampaignEvents|the CampaignEvents page on Meta-Wiki]].
* View all {{formatnum:22}} community-submitted {{PLURAL:22|task|tasks}} that were [[m:Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* Developers with an account on Wikitech-wiki should [[wikitech:Wikitech/SUL-migration|check if any action is required]] for their accounts. The wiki is being changed to use the single-user-login (SUL) system, and other configuration changes. This change will help reduce the overall complexity for the weekly software updates across all our wikis.

'''In depth'''
* The [[m:Special:MyLanguage/Tech/Server switch|server switch]] was completed successfully last week with a read-only time of [[wikitech:Switch Datacenter#Past Switches|only 2 minutes 46 seconds]]. This periodic process makes sure that engineers can switch data centers and keep all of the wikis available for readers, even if there are major technical issues. It also gives engineers a chance to do maintenance and upgrades on systems that normally run 24 hours a day, and often helps to reveal weaknesses in the infrastructure. The process involves dozens of software services and hundreds of hardware servers, and requires multiple teams working together. Work over the past few years has reduced the time from 17 minutes down to 2–3 minutes. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/66ZW7B2MG63AESQVTXDIFQBDBS766JGW/]

'''Meetings and events'''
* October 4–6: [[m:Special:MyLanguage/WikiIndaba conference 2024|WikiIndaba Conference's Hackathon]] in Johannesburg, South Africa
* November 4–6: [[mw:Special:MyLanguage/MediaWiki Users and Developers Conference Fall 2024|MediaWiki Users and Developers Conference Fall 2024]] in Vienna, Austria

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/40|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W40&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:21, 30 September 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27530062 --&gt;

== Tech News: 2024-41 ==

&lt;section begin=&quot;technews-2024-W41&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/41|Translations]] are available.

'''Weekly highlight'''
* Communities can now request installation of [[mw:Special:MyLanguage/Moderator Tools/Automoderator|Automoderator]] on their wiki. Automoderator is an automated anti-vandalism tool that reverts bad edits based on scores from the new &quot;Revert Risk&quot; machine learning model. You can [[mw:Special:MyLanguage/Extension:AutoModerator/Deploying|read details about the necessary steps]] for installation and configuration. [https://phabricator.wikimedia.org/T336934]

'''Updates for editors'''
* Translators in wikis where [[mw:Special:MyLanguage/Content translation/Section translation#Try the tool|the mobile experience of Content Translation is available]], can now customize their articles suggestion list from 41 filtering options when using the tool. This topic-based article suggestion feature makes it easy for translators to self-discover relevant articles based on their area of interest and translate them. You can [https://test.wikipedia.org/w/index.php?title=Special:ContentTranslation&amp;active-list=suggestions try it with your mobile device]. [https://phabricator.wikimedia.org/T368422]
* View all {{formatnum:12}} community-submitted {{PLURAL:12|task|tasks}} that were [[m:Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* It is now possible for &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;&lt;syntaxhighlight&gt;&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; code blocks to offer readers a &quot;Copy&quot; button if the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;copy=1&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; attribute is [[mw:Special:MyLanguage/Extension:SyntaxHighlight#copy|set on the tag]]. Thanks to SD0001 for these improvements. [https://phabricator.wikimedia.org/T40932]
* Customized copyright footer messages on all wikis will be updated. The new versions will use wikitext markup instead of requiring editing raw HTML. [https://phabricator.wikimedia.org/T375789]
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Later this month, [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|temporary accounts]] will be rolled out on several pilot wikis. The final list of the wikis will be published in the second half of the month. If you maintain any tools, bots, or gadgets on [[phab:T376499|these 11 wikis]], and your software is using data about IP addresses or is available for logged-out users, please check if it needs to be updated to work with temporary accounts. [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts/For developers|Guidance on how to update the code is available]].
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Rate limiting has been enabled for the code review tools [[Wikitech:Gerrit|Gerrit]] and [[Wikitech:GitLab|GitLab]] to address ongoing issues caused by malicious traffic and scraping. Clients that open too many concurrent connections will be restricted for a few minutes. This rate limiting is managed through [[Wikitech:nftables|nftables]] firewall rules. For more details, see Wikitech's pages on [[Wikitech:Firewall#Throttling with nftables|Firewall]], [[Wikitech:GitLab/Abuse and rate limiting|GitLab limits]] and [[Wikitech:Gerrit/Operations#Throttling IPs|Gerrit operations]].
* Five new wikis have been created: 
** a {{int:project-localized-name-group-wikipedia}} in [[d:Q49224|Komering]] ([[w:kge:|&lt;code&gt;w:kge:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T374813]
** a {{int:project-localized-name-group-wikipedia}} in [[d:Q36096|Mooré]] ([[m:mos:|&lt;code&gt;m:mos:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T374641]
** a {{int:project-localized-name-group-wiktionary}} in [[d:Q36213|Madurese]] ([[wikt:mad:|&lt;code&gt;wikt:mad:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T374968]
** a {{int:project-localized-name-group-wikiquote}} in [[d:Q2501174|Gorontalo]] ([[q:gor:|&lt;code&gt;q:gor:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T375088]
** a {{int:project-localized-name-group-wikinews}} in [[d:Q56482|Shan]] ([[n:shn:|&lt;code&gt;n:shn:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T375430]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/41|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W41&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:43, 7 October 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27557422 --&gt;

== Wikipedia translation of the week: 2024-42 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Little Danes experiment]]'''&lt;br /&gt; &lt;small&gt;''([[:fa:آزمایش دانمارکی‌های کوچک]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Children play at a Danish Red Cross-run orphanage in Greenland.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''little Danes experiment''' was a 1951 Danish operation where 22 Greenlandic Inuit children were sent to Danish foster families in an attempt to re-educate them as &quot;little Danes&quot;. While the children were all supposed to be orphans, most were not. Six children were adopted while in Denmark, and sixteen returned to Greenland, only to be placed in Danish-speaking orphanages and never live with their families again. Half of the children experienced mental health disturbances, and half of them died in young adulthood. The government of Denmark officially apologised in 2020, after several years of demands from Greenlandic officials. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 03:16, 14 October 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27572997 --&gt;

== Tech News: 2024-42 ==

&lt;section begin=&quot;technews-2024-W42&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/42|Translations]] are available.

'''Updates for editors'''
* The Structured Discussion extension (also known as Flow) is starting to be removed. This extension is unmaintained and causes issues. It will be replaced by [[mw:Special:MyLanguage/Help:DiscussionTools|DiscussionTools]], which is used on any regular talk page. [[mw:Special:MyLanguage/Structured Discussions/Deprecation#Deprecation timeline|A first set of wikis]] are being contacted. These wikis are invited to stop using Flow, and to move all Flow boards to sub-pages, as archives. At these wikis, a script will move all Flow pages that aren't a sub-page to a sub-page automatically, starting on 22 October 2024. On 28 October 2024, all Flow boards at these wikis will be set in read-only mode. [https://www.mediawiki.org/wiki/Structured_Discussions/Deprecation][https://phabricator.wikimedia.org/T370722]
* WMF's Search Platform team is working on making it easier for readers to perform text searches in their language. A [[phab:T332342|change last week]] on over 30 languages makes it easier to find words with accents and other diacritics. This applies to both full-text search and to types of advanced search such as the &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;''hastemplate''&lt;/bdi&gt; and &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;''incategory''&lt;/bdi&gt; keywords. More technical details (including a few other minor search upgrades) are available. [https://www.mediawiki.org/wiki/User:TJones_%28WMF%29/Notes/Language_Analyzer_Harmonization_Notes#ASCII-folding/ICU-folding_%28T332342%29]
* View all {{formatnum:20}} community-submitted {{PLURAL:20|task|tasks}} that were [[m:Tech/News/Recently resolved community tasks|resolved last week]]. For example, [[mw:Special:MyLanguage/Help:Edit check|EditCheck]] was installed at Russian Wikipedia, and fixes were made for some missing user interface styles.

'''Updates for technical contributors'''
* Editors who use the Toolforge tool [[toolforge:copyvios|Earwig's Copyright Violation Detector]] will now be required to log in with their Wikimedia account before running checks using the &quot;search engine&quot; option. This change is needed to help prevent external bots from misusing the system. Thanks to Chlod for these improvements. [https://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers#Authentication_is_now_required_for_search_engine_checks_on_Earwig's_Copyvio_Tool]
* [[m:Special:MyLanguage/Phabricator|Phabricator]] users can create tickets and add comments on existing tickets via Email again. [[mw:Special:MyLanguage/Phabricator/Help#Using email|Sending email to Phabricator]] has been fixed. [https://phabricator.wikimedia.org/T356077]
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Some HTML elements in the interface are now wrapped with a &lt;code&gt;&lt;nowiki&gt;&lt;bdi&gt;&lt;/nowiki&gt;&lt;/code&gt; element, to make our HTML output more aligned with Web standards. More changes like this will be coming in future weeks. This change might break some tools that rely on the previous HTML structure of the interface. Note that relying on the HTML structure of the interface is [[mw:Special:MyLanguage/Stable interface policy/Frontend#What is not stable?|not recommended]] and might break at any time. [https://phabricator.wikimedia.org/T375975]

'''In depth'''
* The latest monthly [[mw:Special:MyLanguage/MediaWiki Product Insights/Reports/September 2024|MediaWiki Product Insights newsletter]] is available. This edition includes: updates on Wikimedia's authentication system, research to simplify feature development in the MediaWiki platform, updates on Parser Unification and MathML rollout, and more.
* The latest quarterly [[mw:Technical Community Newsletter/2024/October|Technical Community Newsletter]] is now available. This edition include: research about improving topic suggestions related to countries, improvements to PHPUnit tests, and more.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/42|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W42&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:22, 14 October 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27597254 --&gt;

== Wikipedia translation of the week: 2024-43 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Kharayeb]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Muharram 1Oth-Ashouraa 2007 in Kharayeb - panoramio.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Kharayeb''' (Arabic: الخرايب) is a historic town in the Sidon District in the South Governorate, Lebanon. The town is 77 km (48 mi) south of Beirut, and stands at an average altitude of 190 m (620 ft) above sea level. The town boasts a rich historical legacy, with archaeological excavations revealing a complex settlement history spanning from Prehistory to the Ottoman period. Notably, Kharayeb's origins can be traced back to the Persian period (539–330 BC), when it played a pivotal role in the region's agricultural and economic landscape, culminating in the construction of its Phoenician temple around the 6th century BC. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:38, 21 October 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27572997 --&gt;

== Tech News: 2024-43 ==

&lt;section begin=&quot;technews-2024-W43&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/43|Translations]] are available.

'''Weekly highlight'''
* The Mobile Apps team has released an [[mw:Special:MyLanguage/Wikimedia Apps/Team/iOS/Navigation Refresh#Phase 1: Creating a user Profile Menu (T373714)|update]] to the iOS app's navigation, and it is now available in the latest App store version. The team added a new Profile menu that allows for easy access to editor features like Notifications and Watchlist from the Article view, and brings the &quot;Donate&quot; button into a more accessible place for users who are reading an article. This is the first phase of a larger planned [[mw:Special:MyLanguage/Wikimedia Apps/Team/iOS/Navigation Refresh|navigation refresh]] to help the iOS app transition from a primarily reader-focused app, to an app that fully supports reading and editing. The Wikimedia Foundation has added more editing features and support for on-wiki communication based on volunteer requests in recent years.
[[File:IOS App Navigation refresh first phase 05.png|thumb|iOS Wikipedia App's profile menu and contents]]

'''Updates for editors'''
* Wikipedia readers can now download a browser extension to experiment with some early ideas on potential features that recommend articles for further reading, automatically summarize articles, and improve search functionality. For more details and to stay updated, check out the Web team's [[mw:Special:MyLanguage/Reading/Web/Content Discovery Experiments|Content Discovery Experiments page]] and [[mw:Special:MyLanguage/Newsletter:Web team's projects|subscribe to their newsletter]].
* Later this month, logged-out editors of [[phab:T376499|these 12 wikis]] will start to have [[mw:Special:Mylanguage/Trust and Safety Product/Temporary Accounts|temporary accounts]] created. The list may slightly change - some wikis may be removed but none will be added. Temporary account is a new [[mw:Special:MyLanguage/User account types|type of user account]]. It enhances the logged-out editors' privacy and makes it easier for community members to communicate with them. If you maintain any tools, bots, or gadgets on these 12 wikis, and your software is using data about IP addresses or is available for logged-out users, please check if it needs to be updated to work with temporary accounts. [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts/For developers|Guidance on how to update the code is available]]. Read more about the [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts/Updates|deployment plan across all wikis]].
* View all {{formatnum:33}} community-submitted {{PLURAL:33|task|tasks}} that were [[m:Tech/News/Recently resolved community tasks|resolved last week]]. For example, the [[w:nr:Main Page|South Ndebele]], [[w:rsk:Главни бок|Pannonian Rusyn]], [[w:ann:Uwu|Obolo]], [[w:iba:Lambar Keterubah|Iban]] and [[w:tdd:ᥞᥨᥝᥴ ᥘᥣᥲ ᥖᥥᥰ|Tai Nüa]] Wikipedia languages were created last week. [https://www.wikidata.org/wiki/Q36785][https://www.wikidata.org/wiki/Q35660][https://www.wikidata.org/wiki/Q36614][https://www.wikidata.org/wiki/Q33424][https://www.wikidata.org/wiki/Q36556]
* It is now possible to create functions on Wikifunctions using Wikidata lexemes, through the new [[f:Z6005|Wikidata lexeme type]] launched last week. When you go to one of these functions, the user interface provides a lexeme selector that helps you pick a lexeme from Wikidata that matches the word you type. After hitting run, your selected lexeme is retrieved from Wikidata, transformed into a Wikidata lexeme type, and passed into the selected function. Read more about this in [[f:Special:MyLanguage/Wikifunctions:Status updates/2024-10-17#Function of the Week: select representation from lexeme|the latest Wikifunctions newsletter]].

'''Updates for technical contributors'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Users of the Wikimedia sites can now format dates more easily in different languages with the new &lt;code dir=&quot;ltr&quot;&gt;{{[[mw:Special:MyLanguage/Help:Extension:ParserFunctions##timef|#timef]]:…}}&lt;/code&gt; parser function. For example, &lt;code dir=&quot;ltr&quot;&gt;&lt;nowiki&gt;{{#timef:now|date|en}}&lt;/nowiki&gt;&lt;/code&gt; will show as &quot;&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;{{#timef:now|date|en}}&lt;/bdi&gt;&quot;. Previously, &lt;code dir=&quot;ltr&quot;&gt;&lt;nowiki&gt;{{#time:…}}&lt;/nowiki&gt;&lt;/code&gt; could be used to format dates, but this required knowledge of the order of the time and date components and their intervening punctuation. &lt;code dir=&quot;ltr&quot;&gt;#timef&lt;/code&gt; (or &lt;code dir=&quot;ltr&quot;&gt;#timefl&lt;/code&gt; for local time) provides access to the standard date formats that MediaWiki uses in its user interface. This may help to simplify some templates on multi-lingual wikis like Commons and Meta. [https://phabricator.wikimedia.org/T223772][https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Extension:ParserFunctions##timef]
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Commons and Meta users can now efficiently [[mw:Special:MyLanguage/Help:Magic words#Localization|retrieve the user's language]] using &lt;code dir=&quot;ltr&quot;&gt;&lt;nowiki&gt;{{USERLANGUAGE}}&lt;/nowiki&gt;&lt;/code&gt; instead of using &lt;code dir=&quot;ltr&quot;&gt;&lt;nowiki&gt;{{int:lang}}&lt;/nowiki&gt;&lt;/code&gt;. [https://phabricator.wikimedia.org/T4085]
* The [[m:Special:MyLanguage/Product and Technology Advisory Council|Product and Tech Advisory Council]] (PTAC) now has its pilot members with representation across Africa, Asia, Europe, North America and South America. They will work to address the [[Special:MyLanguage/Movement Strategy/Initiatives/Technology Council|Movement Strategy's Technology Council]] initiative of having a co-defined and more resilient technological platform. [https://meta.wikimedia.org/wiki/Movement_Strategy/Initiatives/Technology_Council]

'''In depth'''
* The latest quarterly [[mw:Special:MyLanguage/Growth/Newsletters/32|Growth newsletter]] is available. It includes: an upcoming Newcomer Homepage Community Updates module, new Community Configuration options, and details on new projects.
* The Wikimedia Foundation is [[mw:Special:MyLanguage/Wikimedia Security Team#CNA Partnership|now an official partner of the CVE program]], which is an international effort to catalog publicly disclosed cybersecurity vulnerabilities. This partnership will allow the Security Team to instantly publish [[w:en:Common Vulnerabilities and Exposures|common vulnerabilities and exposures]] (CVE) records that are affecting MediaWiki core, extensions, and skins, along with any other code the Foundation is a steward of.
* The [[m:Special:MyLanguage/Community Wishlist|Community Wishlist]] is now [[m:Community Wishlist/Updates#October 16, 2024: Conversations Made Easier: Machine-Translated Wishes Are Here!|testing machine translations]] for Wishlist content. Volunteers can now read machine-translated versions of wishes and dive into discussions even before translators arrive to translate content.

'''Meetings and events'''
* 24 October - Wiki Education Speaker Series Webinar - [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/N4XTB4G55BUY3M3PNGUAKQWJ7A4UOPAK/ Open Source Tech: Building the Wiki Education Dashboard], featuring Wikimedia interns and a Web developer in the panel.
* 20–22 December 2024 - [[m:Special:MyLanguage/Indic Wikimedia Hackathon Bhubaneswar 2024|Indic Wikimedia Hackathon Bhubaneswar 2024]] in Odisha, India. A hackathon for community members, including developers, designers and content editors, to build technical solutions that improve contributors' experiences.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/43|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W43&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:53, 21 October 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27634672 --&gt;

== Wikipedia translation of the week: 2024-44 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Christmas horror]]'''&lt;br /&gt; &lt;small&gt;''([[:es:Terror navideño]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Christmascarol1843 -- 169.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Christmas horror''' is a fiction genre and film genre that incorporates horror elements into a seasonal setting. It is popular in multiple countries.  

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:05, 28 October 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27647428 --&gt;

== Tech News: 2024-44 ==

&lt;section begin=&quot;technews-2024-W44&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/44|Translations]] are available.

'''Updates for editors'''
* Later in November, the Charts extension will be deployed to the test wikis in order to help identify and fix any issue. A security review is underway to then enable deployment to pilot wikis for broader testing. You can read [[mw:Special:MyLanguage/Extension:Chart/Project/Updates#October 2024: Working towards production deployment|the October project update]] and see the [https://en.wikipedia.beta.wmflabs.org/wiki/Charts latest documentation and examples on Beta Wikipedia].
* View all {{formatnum:32}} community-submitted {{PLURAL:32|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, [[w:en:PediaPress|Pediapress.com]], an external service that creates books from Wikipedia, can now use [[mw:Special:MyLanguage/Wikimedia Maps|Wikimedia Maps]] to include existing pre-rendered infobox map images in their printed books on Wikipedia. [https://phabricator.wikimedia.org/T375761]

'''Updates for technical contributors'''
* Wikis can use [[:mw:Special:MyLanguage/Extension:GuidedTour|the Guided Tour extension]] to help newcomers understand how to edit. The Guided Tours extension now works with [[mw:Special:MyLanguage/Manual:Dark mode|dark mode]]. Guided Tour maintainers can check their tours to see that nothing looks odd. They can also set &lt;code&gt;emitTransitionOnStep&lt;/code&gt; to &lt;code&gt;true&lt;/code&gt; to fix an old bug. They can use the new flag &lt;code&gt;allowAutomaticBack&lt;/code&gt; to avoid back-buttons they don't want. [https://phabricator.wikimedia.org/T73927#10241528]
*  Administrators in the Wikimedia projects who use the [[mw:Special:MyLanguage/Help:Extension:Nuke|Nuke Extension]] will notice that mass deletions done with this tool have the &quot;Nuke&quot; tag. This change will make reviewing and analyzing deletions performed with the tool easier. [https://phabricator.wikimedia.org/T366068]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/44|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W44&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:57, 28 October 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27668811 --&gt;

== Wikipedia translation of the week: 2024-45 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Placenta cake]]'''&lt;br /&gt; &lt;small&gt;''([[:simple:Placenta cake]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Bucharest, Greek pie-maker, 1880.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Placenta cake''' is a dish from ancient Greece and Rome consisting of many dough layers interspersed with a mixture of cheese and honey and flavored with bay leaves, baked and then covered in honey. The dessert is mentioned in classical texts such as the Greek poems of Archestratos and Antiphanes, as well as the De agri cultura of Cato the Elder. It is often seen as the predecessor of baklava and börek. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:16, 4 November 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27647428 --&gt;

== Tech News: 2024-45 ==

&lt;section begin=&quot;technews-2024-W45&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/45|Translations]] are available.

'''Updates for editors'''
* Stewards can now make [[m:Special:MyLanguage/Global blocks|global account blocks]] cause global [[mw:Special:MyLanguage/Autoblock|autoblocks]]. This will assist stewards in preventing abuse from users who have been globally blocked. This includes preventing globally blocked temporary accounts from exiting their session or switching browsers to make subsequent edits for 24 hours. Previously, temporary accounts could exit their current session or switch browsers to continue editing. This is an anti-abuse tool improvement for the [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|Temporary Accounts]] project. You can read more about the [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts/Updates|progress on key features for temporary accounts]]. [https://phabricator.wikimedia.org/T368949]
* Wikis that have the [[m:Special:MyLanguage/CampaignEvents/Deployment status|CampaignEvents extension enabled]] can now use the [[m:Special:MyLanguage/Campaigns/Foundation Product Team/Event list#October 29, 2024: Collaboration List launched|Collaboration List]] feature. This list provides a new, easy way for contributors to learn about WikiProjects on their wikis. Thanks to the Campaign team for this work that is part of [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2024-2025/Product %26 Technology OKRs#WE KRs|the 2024/25 annual plan]]. If you are interested in bringing the CampaignEvents extension to your wiki, you can [[m:Special:MyLanguage/CampaignEvents/Deployment status#How to Request the CampaignEvents Extension for your wiki|follow these steps]] or you can reach out to User:Udehb-WMF for help.
* The text color for red links will be slightly changed later this week to improve their contrast in light mode. [https://phabricator.wikimedia.org/T370446]
* View all {{formatnum:32}} community-submitted {{PLURAL:32|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, on multilingual wikis, users [[phab:T216368|can now]] hide translations from the WhatLinksHere special page.

'''Updates for technical contributors'''
* XML [[m:Special:MyLanguage/Data dumps|data dumps]] have been temporarily paused whilst a bug is investigated. [https://lists.wikimedia.org/hyperkitty/list/xmldatadumps-l@lists.wikimedia.org/message/BXWJDPO5QI2QMBCY7HO36ELDCRO6HRM4/]

'''In depth'''
* Temporary Accounts have been deployed to six wikis; thanks to the Trust and Safety Product team for [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|this work]], you can read about [[phab:T340001|the deployment plans]]. Beginning next week, Temporary Accounts will also be enabled on [[phab:T378336|seven other projects]]. If you are active on these wikis and need help migrating your tools, please reach out to [[m:User:Udehb-WMF|User:Udehb-WMF]] for assistance.
*  The latest quarterly [[mw:Special:MyLanguage/Wikimedia Language and Product Localization/Newsletter/2024/October|Language and Internationalization newsletter]] is available.  It includes: New languages supported in translatewiki or in MediaWiki; New keyboard input methods for some languages; details about recent and upcoming meetings, and more.

'''Meetings and events'''
* [[mw:Special:MyLanguage/MediaWiki Users and Developers Conference Fall 2024|MediaWiki Users and Developers Conference Fall 2024]] is happening in Vienna, Austria and online from 4 to 6 November 2024. The conference will feature discussions around the usage of MediaWiki software by and within companies in different industries and will inspire and onboard new users.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/45|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W45&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:51, 4 November 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27693917 --&gt;

== Wikipedia translation of the week: 2024-46 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Trisomy 16]]'''&lt;br /&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Chromosome 16.svg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Trisomy 16''' is a chromosomal abnormality in which there are 3 copies of chromosome 16 rather than two. It is the most common trisomy leading to miscarriage and the second most common chromosomal cause of it, closely following X-chromosome monosomy. About 6% of miscarriages have trisomy 16. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:09, 11 November 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27708700 --&gt;

== Tech News: 2024-46 ==

&lt;section begin=&quot;technews-2024-W46&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/46|Translations]] are available.

'''Updates for editors'''
* On wikis with the [[mw:Special:MyLanguage/Help:Extension:Translate|Translate extension]] enabled, users will notice that the FuzzyBot will now automatically create translated versions of categories used on translated pages. [https://phabricator.wikimedia.org/T285463]
* View all {{formatnum:29}} community-submitted {{PLURAL:29|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the submitted task to use the [[mw:Special:MyLanguage/Extension:SecurePoll|SecurePoll extension]] for English Wikipedia's special [[w:en:Wikipedia:Administrator elections|administrator election]] was resolved on time. [https://phabricator.wikimedia.org/T371454] 

'''Updates for technical contributors'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] In &lt;code dir=&quot;ltr&quot;&gt;[[mw:MediaWiki_1.44/wmf.2|1.44.0-wmf-2]]&lt;/code&gt;, the logic of Wikibase function &lt;code&gt;getAllStatements&lt;/code&gt; changed to behave like &lt;code&gt;getBestStatements&lt;/code&gt;. Invoking the function now returns a copy of values which are immutable. [https://phabricator.wikimedia.org/T270851]
* [https://en.wikipedia.org/api/rest_v1/ Wikimedia REST API] users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. The API will be rerouting some page content endpoints from RESTbase to the newer [[mw:Special:MyLanguage/API:REST API|MediaWiki REST API]] endpoints. The [[phab:T374683|impacted endpoints]] include getting page/revision metadata and rendered HTML content. These changes will be available on testwiki later this week, with other projects to follow. This change should not affect existing functionality, but active users of the impacted endpoints should verify behavior on testwiki, and raise any concerns on the related [[phab:T374683|Phabricator ticket]].

'''In depth'''
* Admins and users of the Wikimedia projects [[mw:Special:MyLanguage/Moderator_Tools/Automoderator#Usage|where Automoderator is enabled]] can now monitor and evaluate important metrics related to Automoderator's actions. [https://superset.wmcloud.org/superset/dashboard/unified-automoderator-activity-dashboard/ This Superset dashboard] calculates and aggregates metrics about Automoderator's behaviour on the projects in which it is deployed. Thanks to the Moderator Tools team for this Dashboard; you can visit [[mw:Special:MyLanguage/Moderator Tools/Automoderator/Unified Activity Dashboard|the documentation page]] for more information about this work. [https://phabricator.wikimedia.org/T369488]

'''Meetings and events'''
* 21 November 2024 ([[m:Special:MyLanguage/Event:Commons community discussion - 21 November 2024 8:00 UTC|8:00 UTC]] &amp; [[m:Special:MyLanguage/Event:Commons community discussion - 21 November 2024 16:00 UTC|16:00 UTC]]) - [[c:Commons:WMF support for Commons/Commons community calls|Community call]] with Wikimedia Commons volunteers and stakeholders to help prioritize support efforts for 2025-2026 Fiscal Year. The theme of this call is how content should be organised on Wikimedia Commons.
'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/46|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W46&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:08, 12 November 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27732268 --&gt;

== Wikipedia translation of the week: 2024-47 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Boana platanera]]'''&lt;br /&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Rana platanera - Boana platanera.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''Boana platanera''''', commonly known as the banana tree dwelling frog, is a species of tree frog in the family Hylidae. It is distributed within Venezuela, Colombia, Panama, and Trinidad and Tobago. Boana platanera was described in 2021, and individuals of the species were previously classified as Boana crepitans or Boana xerophylla. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:53, 18 November 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27735014 --&gt;

== Tech News: 2024-47 ==

&lt;section begin=&quot;technews-2024-W47&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/47|Translations]] are available.

'''Updates for editors'''
* Users of Wikimedia sites will now be warned when they create a [[mw:Special:MyLanguage/Help:Redirects|redirect]] to a page that doesn't exist. This will reduce the number of broken redirects to red links in our projects. [https://phabricator.wikimedia.org/T326057]
* View all {{formatnum:42}} community-submitted {{PLURAL:42|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, [[mw:Special:MyLanguage/Manual:Pywikibot/Overview|Pywikibot]], which automates work on MediaWiki sites, was upgraded to 9.5.0 on Toolforge. [https://phabricator.wikimedia.org/T378676]

'''Updates for technical contributors'''
* On wikis that use the [[mw:Special:MyLanguage/Extension:FlaggedRevs|FlaggedRevs extension]], pages created or moved by users with the appropriate permissions are marked as flagged automatically. This feature has not been working recently, and changes fixing it should be deployed this week. Thanks to Daniel and Wargo for working on this. [https://phabricator.wikimedia.org/T379218][https://phabricator.wikimedia.org/T368380]

'''In depth'''
* There is a new [https://diff.wikimedia.org/2024/11/05/say-hi-to-temporary-accounts-easier-collaboration-with-logged-out-editors-with-better-privacy-protection Diff post] about Temporary Accounts, available in more than 15 languages. Read it to learn about what Temporary Accounts are, their impact on different groups of users, and the plan to introduce the change on all wikis.

'''Meetings and events'''
* Technical volunteers can now register for the [[mw:Special:MyLanguage/Wikimedia Hackathon 2025|2025 Wikimedia Hackathon]], which will take place in Istanbul, Turkey. [https://pretix.eu/wikimedia/hackathon2025/ Application for travel and accommodation scholarships] is open from '''November 12 to December 10 2024'''. The registration for the event will close in mid-April 2025. The Wikimedia Hackathon is an annual gathering that unites the global technical community to collaborate on existing projects and explore new ideas.
* Join the [[C:Special:MyLanguage/Commons:WMF%20support%20for%20Commons/Commons%20community%20calls|Wikimedia Commons community calls]] this week to help prioritize support for Commons which will be planned for 2025–2026. The theme will be how content should be organised on Wikimedia Commons. This is an opportunity for volunteers who work on different things to come together and talk about what matters for the future of the project. The calls will take place '''November 21, 2024, [[m:Special:MyLanguage/Event:Commons community discussion - 21 November 2024 8:00 UTC|8:00 UTC]] and [[m:Special:MyLanguage/Event:Commons community discussion - 21 November 2024 16:00 UTC|16:00 UTC]]'''.
* A [[mw:Special:MyLanguage/Wikimedia_Language_and_Product_Localization/Community meetings#29 November 2024|Language community meeting]] will take place '''November 29, 16:00 UTC''' to discuss updates and technical problem-solving.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/47|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W47&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 02:01, 19 November 2024 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27806858 --&gt;

== Wikipedia translation of the week: 2024-48 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Wang Su-bok]]'''&lt;br /&gt; &lt;small&gt;''([[:fa:وانگ سو بوک]])&amp;#32;([[:ko:왕수복]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Wang Su-bok''' was a singer from North Korea, who was the most popular singer in Japanese-occupied Korea in 1935. She was credited as a ground-breaking female artist, whose work led the way for the modern K-pop phenomenon. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:57, 25 November 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27846897 --&gt;

== Tech News: 2024-48 ==

&lt;section begin=&quot;technews-2024-W48&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/48|Translations]] are available.

'''Updates for editors'''
* [[File:Octicons-gift.svg|12px|link=|class=skin-invert|Wishlist item]] A new version of the standard wikitext editor-mode [[mw:Special:MyLanguage/Extension:CodeMirror|syntax highlighter]] will be available as a [[Special:Preferences#mw-prefsection-betafeatures|beta feature]] later this week. This brings many new features and bug fixes, including right-to-left support, [[mw:Special:MyLanguage/Help:Extension:CodeMirror#Template folding|template folding]], [[mw:Special:MyLanguage/Help:Extension:CodeMirror#Autocompletion|autocompletion]], and an improved search panel. You can learn more on the [[mw:Special:MyLanguage/Help:Extension:CodeMirror|help page]].
* The 2010 wikitext editor now supports common keyboard shortcuts such &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;Ctrl&lt;/code&gt;+&lt;code&gt;B&lt;/code&gt;&lt;/bdi&gt; for bold and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;Ctrl&lt;/code&gt;+&lt;code&gt;I&lt;/code&gt;&lt;/bdi&gt; for italics. A full [[mw:Help:Extension:WikiEditor#Keyboard shortcuts|list of all six shortcuts]] is available. Thanks to SD0001 for this improvement. [https://phabricator.wikimedia.org/T62928]
* Starting November 28, Flow/Structured Discussions pages will be automatically archived and set to read-only at the following wikis: &lt;bdi&gt;bswiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;elwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;euwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;fawiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;fiwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;frwikiquote&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;frwikisource&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;frwikiversity&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;frwikivoyage&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;idwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;lvwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;plwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;ptwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;urwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;viwikisource&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;zhwikisource&lt;/bdi&gt;. This is done as part of [[mw:Special:MyLanguage/Structured_Discussions/Deprecation|StructuredDiscussions deprecation work]]. If you need any assistance to archive your page in advance, please contact [[m:User:Trizek (WMF)|Trizek (WMF)]]. 
* View all {{formatnum:25}} community-submitted {{PLURAL:25|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a user creating a new AbuseFilter can now only set the filter to &quot;protected&quot; [[phab:T377765|if it includes a protected variable]].

'''Updates for technical contributors'''
* The [[mw:Special:MyLanguage/Extension:CodeEditor|CodeEditor]], which can be used in JavaScript, CSS, JSON, and Lua pages, [[phab:T377663|now offers]] live autocompletion. Thanks to SD0001 for this improvement. The feature can be temporarily disabled on a page by pressing &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;Ctrl&lt;/code&gt;+&lt;code&gt;,&lt;/code&gt;&lt;/bdi&gt; and un-selecting &quot;&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;Live Autocompletion&lt;/bdi&gt;&quot;.
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Tool-maintainers who use the Graphite system for tracking metrics, need to migrate to the newer Prometheus system. They can check [https://grafana.wikimedia.org/d/K6DEOo5Ik/grafana-graphite-datasource-utilization?orgId=1 this dashboard] and the list in the Description of the [[phab:T350592|task T350592]] to see if their tools are listed, and they should claim metrics and dashboards connected to their tools. They can then disable or migrate all existing metrics by following the instructions in the task. The Graphite service will become read-only in April. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/KLUV4IOLRYXPQFWD6WKKJUHMWE77BMSZ/]
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] The [[mw:Special:MyLanguage/NewPP parser report|New PreProcessor parser performance report]] has been fixed to give an accurate count for the number of Wikibase entities accessed. It had previously been resetting after 400 entities. [https://phabricator.wikimedia.org/T279069]

'''Meetings and events'''
* A [[mw:Special:MyLanguage/Wikimedia_Language_and_Product_Localization/Community meetings#29 November 2024|Language community meeting]] will take place November 29 at [https://zonestamp.toolforge.org/1732896000 16:00 UTC]. There will be presentations on topics like developing language keyboards, the creation of the Mooré Wikipedia, the language support track at [[m:Wiki Indaba|Wiki Indaba]], and a report from the Wayuunaiki community on their experiences with the Incubator and as a new community over the last 3 years. This meeting will be in English and will also have Spanish interpretation.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/48|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W48&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:42, 25 November 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27847039 --&gt;

== Wikipedia translation of the week: 2024-49 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Storm Filomena]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Spain’s chilly blanket ESA22415247.jpeg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Storm Filomena''' was an extratropical cyclone in early January 2021 that was most notable for bringing unusually heavy snowfall to parts of Spain, with Madrid recording its heaviest snowfall in over a century, and with Portugal being hit less severely. The eighth named storm of the 2020–21 European windstorm season, Filomena formed over the Atlantic Ocean close to the Canary Islands on 7 January, subsequently taking a slow track north-eastwards towards the Iberian Peninsula and then eastwards across the Mediterranean Sea. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:48, 2 December 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27846897 --&gt;

== Tech News: 2024-49 ==

&lt;section begin=&quot;technews-2024-W49&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/49|Translations]] are available.

'''Updates for editors'''
* Two new parser functions were added this week. The &lt;code dir=&quot;ltr&quot;&gt;&lt;nowiki&gt;{{&lt;/nowiki&gt;[[mw:Special:MyLanguage/Help:Magic words#interwikilink|#interwikilink]]&lt;nowiki&gt;}}&lt;/nowiki&gt;&lt;/code&gt; function adds an [[mw:Special:MyLanguage/Help:Links#Interwiki links|interwiki link]] and the &lt;code dir=&quot;ltr&quot;&gt;&lt;nowiki&gt;{{&lt;/nowiki&gt;[[mw:Special:MyLanguage/Help:Magic words#interlanguagelink|#interlanguagelink]]&lt;nowiki&gt;}}&lt;/nowiki&gt;&lt;/code&gt; function adds an [[mw:Special:MyLanguage/Help:Links#Interlanguage links|interlanguage link]]. These parser functions are useful on wikis where namespaces conflict with interwiki prefixes. For example, links beginning with &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;MOS:&lt;/code&gt;&lt;/bdi&gt; on English Wikipedia [[phab:T363538|conflict with the &lt;code&gt;mos&lt;/code&gt; language code prefix of Mooré Wikipedia]].
* Starting this week, Wikimedia wikis no longer support connections using old RSA-based HTTPS certificates, specifically rsa-2048. This change is to improve security for all users. Some older, unsupported browser or smartphone devices will be unable to connect; Instead, they will display a connectivity error. See the [[wikitech:HTTPS/Browser_Recommendations|HTTPS Browser Recommendations page]] for more-detailed information. All modern operating systems and browsers are always able to reach Wikimedia projects. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/CTYEHVNSXUD3NFAAMG3BLZVTVQWJXJAH/]
* Starting December 16, Flow/Structured Discussions pages will be automatically archived and set to read-only at the following wikis: &lt;bdi&gt;arwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;cawiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;frwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;mediawikiwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;orwiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;wawiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;wawiktionary&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;wikidatawiki&lt;/bdi&gt;{{int:comma-separator/en}}&lt;bdi&gt;zhwiki&lt;/bdi&gt;. This is done as part of [[mw:Special:MyLanguage/Structured_Discussions/Deprecation|StructuredDiscussions deprecation work]]. If you need any assistance to archive your page in advance, please contact [[m:User:Trizek (WMF)|Trizek (WMF)]]. [https://phabricator.wikimedia.org/T380910]
* This month the Chart extension was deployed to production and is now available on Commons and Testwiki. With the security review complete, pilot wiki deployment is expected to start in the first week of December. You can see a working version [[testwiki:Charts|on Testwiki]] and read [[mw:Special:MyLanguage/Extension:Chart/Project/Updates|the November project update]] for more details.
* View all {{formatnum:23}} community-submitted {{PLURAL:23|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a bug with the &quot;Download as PDF&quot; system was fixed. [https://phabricator.wikimedia.org/T376438]

'''Updates for technical contributors'''
* In late February, temporary accounts will be rolled out on at least 10 large wikis. This deployment will have a significant effect on the community-maintained code. This is about Toolforge tools, bots, gadgets, and user scripts that use IP address data or that are available for logged-out users. The Trust and Safety Product team wants to identify this code, monitor it, and assist in updating it ahead of the deployment to minimize disruption to workflows. The team asks technical editors and volunteer developers to help identify such tools by adding them to [[mw:Trust and Safety Product/Temporary Accounts/For developers/Impacted tools|this list]]. In addition, review the [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts/For developers|updated documentation]] to learn how to adjust the tools. Join the discussions on the [[mw:Talk:Trust and Safety Product/Temporary Accounts|project talk page]] or in the [[discord:channels/221049808784326656/1227616742340034722|dedicated thread]] on the [[w:Wikipedia:Discord|Wikimedia Community Discord server (in English)]] for support and to share feedback. 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/49|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W49&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:23, 2 December 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27873992 --&gt;

== Wikipedia translation of the week: 2024-50 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Syrian literature]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Poem about Baybars page 1 from Hakawati book.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Syrian literature''' is modern fiction written or orally performed in Arabic by writers from Syria since the independence of the Syrian Arab Republic in 1946. It is part of the historically and geographically wider Arabic literature. The modern states of Syria, Lebanon, Jordan, Israel as well as the Palestinian autonomous areas only came into being in the mid-20th century. Therefore, Syrian literature has since been referred to by literary scholarship as the national literature of the Syrian Arab Republic, as well as the works created in Arabic by Syrian writers in the diaspora. This literature has been influenced by the country's political history, the literature of other Arabic-speaking countries and, especially in its early days, by French literature. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:59, 9 December 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27846897 --&gt;

== Tech News: 2024-50 ==

&lt;section begin=&quot;technews-2024-W50&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/50|Translations]] are available.

'''Weekly highlight'''
* Technical documentation contributors can find updated resources, and new ways to connect with each other and the Wikimedia Technical Documentation Team, at the [[mw:Special:MyLanguage/Documentation|Documentation hub]] on MediaWiki.org. This page links to: resources for writing and improving documentation, a new &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;#wikimedia-techdocs&lt;/bdi&gt; IRC channel on libera.chat, a listing of past and upcoming documentation events, and ways to request a documentation consultation or review. If you have any feedback or ideas for improvements to the documentation ecosystem, please [[mw:Wikimedia Technical Documentation Team#Contact us|contact the Technical Documentation Team]].

'''Updates for editors'''
[[File:Edit Check on Desktop.png|thumb|Layout change for the Edit Check feature]]
* Later this week, [[mw:Special:MyLanguage/Edit check|Edit Check]] will be relocated to a sidebar on desktop. Edit check is the feature for new editors to help them follow policies and guidelines. This layout change creates space to present people with [[mw:Edit check#1 November 2024|new Checks]] that appear ''while'' they are typing. The [[mw:Special:MyLanguage/Edit check#Reference Check A/B Test|initial results]] show newcomers encountering Edit Check are 2.2 times more likely to publish a new content edit that includes a reference and is not reverted.
* The Chart extension, which enables editors to create data visualizations, was successfully made available on MediaWiki.org and three pilot wikis (Italian, Swedish, and Hebrew Wikipedias). You can see a working examples [[testwiki:Charts|on Testwiki]] and read [[mw:Special:MyLanguage/Extension:Chart/Project/Updates|the November project update]] for more details.
* Translators in wikis where the [[mw:Special:MyLanguage/Content translation/Section translation#Try the tool|mobile experience of Content Translation is available]], can now discover articles in Wikiproject campaigns of their interest from the &quot;[https://test.wikipedia.org/w/index.php?title=Special:ContentTranslation&amp;campaign=specialcx&amp;filter-type=automatic&amp;filter-id=collections&amp;active-list=suggestions&amp;from=es&amp;to=en All collection]&quot; category in the articles suggestion feature. Wikiproject Campaign organizers can use this feature, to help translators to discover articles of interest, by adding the &lt;code dir=ltr&gt;&lt;nowiki&gt;&lt;page-collection&gt; &lt;/page-collection&gt;&lt;/nowiki&gt;&lt;/code&gt; tag to their campaign article list page on Meta-wiki. This will make those articles discoverable in the Content Translation tool. For more detailed information on how to use the tool and tag, please refer to [[mw:Special:MyLanguage/Translation suggestions: Topic-based &amp; Community-defined lists/How to use the features|the step-by-step guide]]. [https://phabricator.wikimedia.org/T378958]
* The [[mw:Special:MyLanguage/Extension:Nuke|Nuke]] feature, which enables administrators to mass delete pages, now has a [[phab:T376379#10310998|multiselect filter for namespace selection]]. This enables users to select multiple specific namespaces, instead of only one or all, when fetching pages for deletion.
* The Nuke feature also now [[phab:T364225#10371365|provides links]] to the userpage of the user whose pages were deleted, and to the pages which were not selected for deletion, after page deletions are queued. This enables easier follow-up admin-actions. Thanks to Chlod and the Moderator Tools team for both of these improvements. [https://phabricator.wikimedia.org/T364225#10371365]
* The Editing Team is working on making it easier to populate citations from archive.org using the [[mw:Special:MyLanguage/Citoid/Enabling Citoid on your wiki|Citoid]] tool, the auto-filled citation generator. They are asking communities to add two parameters preemptively, &lt;code dir=ltr&gt;archiveUrl&lt;/code&gt; and &lt;code dir=ltr&gt;archiveDate&lt;/code&gt;, within the TemplateData for each citation template using Citoid. You can see an [https://en.wikipedia.org/w/index.php?title=Template%3ACite_web%2Fdoc&amp;diff=1261320172&amp;oldid=1260788022 example of a change in a template], and a [https://global-search.toolforge.org/?namespaces=10&amp;q=%5C%22citoid%5C%22%3A%20%5C%7B&amp;regex=1&amp;title= list of all relevant templates]. [https://phabricator.wikimedia.org/T374831]
* One new wiki has been created: a {{int:project-localized-name-group-wikivoyage}} in [[d:Q9240|Indonesian]] ([[voy:id:|&lt;code&gt;voy:id:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T380726]
* Last week, all wikis had problems serving pages to logged-in users and some logged-out users for 30–45 minutes. This was caused by a database problem, and investigation is ongoing. [https://www.wikimediastatus.net/incidents/3g2ckc7bp6l9]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:19}} community-submitted {{PLURAL:19|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a bug in the [[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add Link]] feature has been fixed. Previously, the list of sections which are excluded from Add Link was partially ignored in certain cases. [https://phabricator.wikimedia.org/T380455][https://phabricator.wikimedia.org/T380329]

'''Updates for technical contributors'''
* [[mw:Special:MyLanguage/Codex|Codex]], the design system for Wikimedia, now has an early-stage [[gitiles:design/codex-php|implementation in PHP]]. It is available for general use in MediaWiki extensions and Toolforge apps through [https://packagist.org/packages/wikimedia/codex Composer], with use in MediaWiki core coming soon. More information is available in [[wmdoc:design-codex-php/main/index.html|the documentation]]. Thanks to Doğu for the inspiration and many contributions to the library. [https://phabricator.wikimedia.org/T379662]
* [https://en.wikipedia.org/api/rest_v1/ Wikimedia REST API] users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. On December 4, the MediaWiki Interfaces team began rerouting page/revision metadata and rendered HTML content endpoints on [[testwiki:|testwiki]] from RESTbase to comparable MediaWiki REST API endpoints. The team encourages active users of these endpoints to verify their tool's behavior on testwiki and raise any concerns on the related [[phab:T374683|Phabricator ticket]] before the end of the year, as they intend to roll out the same change across all Wikimedia projects in early January. These changes are part of the work to replace the outdated [[mw:RESTBase/deprecation|RESTBase]] system.
* The [https://wikimediafoundation.limesurvey.net/986172 2024 Developer Satisfaction Survey] is seeking the opinions of the Wikimedia developer community. Please take the survey if you have any role in developing software for the Wikimedia ecosystem. The survey is open until 3 January 2025, and has an associated [[foundation:Legal:Developer Satisfaction Survey 2024 Privacy Statement|privacy statement]].
* There is no new MediaWiki version this week. [https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar]

'''Meetings and events'''
* The next meeting in the series of [[c:Commons:WMF support for Commons/Commons community calls|Wikimedia Foundation discussions with the Wikimedia Commons community]] will take place on [[m:Event:Commons community discussion - 12 December 2024 08:00 UTC|December 12 at 8:00 UTC]] and [[m:Event:Commons community discussion - 12_December 2024 16:00 UTC|at 16:00 UTC]]. The topic of this call is new media and new contributors. Contributors from all wikis are welcome to attend.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/50|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W50&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:16, 9 December 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27919424 --&gt;

== Wikipedia translation of the week: 2024-51 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Mars ocean theory]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:AncientMars.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Mars ocean theory''' states that nearly a third of the surface of Mars was covered by an ocean of liquid water early in the planet's geologic history. This primordial ocean, dubbed Paleo-Ocean or Oceanus Borealis (/oʊˈsiːənəs ˌbɒriˈælɪs/ oh-SEE-ə-nəs BORR-ee-AL-iss), would have filled the basin Vastitas Borealis in the northern hemisphere, a region that lies 4–5 km (2.5–3 miles) below the mean planetary elevation, at a time period of approximately 4.1–3.8 billion years ago. Evidence for this ocean includes geographic features resembling ancient shorelines, and the chemical properties of the Martian soil and atmosphere 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:44, 16 December 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27933909 --&gt;

== Tech News: 2024-51 ==

&lt;section begin=&quot;technews-2024-W51&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2024/51|Translations]] are available.

'''Weekly highlight'''
* Interested in improving event management on your home wiki? The [[m:Special:MyLanguage/CampaignEvents|CampaignEvents extension]] offers organizers features like event registration management, event/wikiproject promotion, finding potential participants, and more - all directly on-wiki. If you are an organizer or think your community would benefit from this extension, start a discussion to enable it on your wiki today. To learn more about how to enable this extension on your wiki, visit the [[m:CampaignEvents/Deployment status#How to Request the CampaignEvents Extension for your wiki|deployment status page]].

'''Updates for editors'''
* Users of the iOS Wikipedia App in Italy and Mexico on the Italian, Spanish, and English Wikipedias, can see a [[mw:Special:MyLanguage/Wikimedia Apps/Team/iOS/Personalized Wikipedia Year in Review|personalized Year in Review]] with insights based on their reading and editing history.
* Users of the Android Wikipedia App in Sub-Saharan Africa and South Asia can see the new [[mw:Special:MyLanguage/Wikimedia Apps/Team/Android/Rabbit Holes|Rabbit Holes]] feature. This feature shows a suggested search term in the Search bar based on the current article being viewed, and a suggested reading list generated from the user’s last two visited articles.
* The [[m:Special:MyLanguage/Global reminder bot|global reminder bot]] is now active and running on nearly 800 wikis. This service reminds most users holding temporary rights when they are about to expire, so that they can renew should they want to. See [[m:Global reminder bot/Technical details|the technical details page]] for more information.
* The next issue of Tech News will be sent out on 13 January 2025 because of the end of year holidays. Thank you to all of the translators, and people who submitted content or feedback, this year.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a bug was [[phab:T374988|fixed]] in the Android Wikipedia App which had caused translatable SVG images to show the wrong language when they were tapped.

'''Updates for technical contributors'''
* There is no new MediaWiki version next week. The next deployments will start on 14 January. [https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar/2025] 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2024/51|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2024-W51&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:25, 16 December 2024 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=27942374 --&gt;

== Wikipedia translation of the week: 2024-52 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2024 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:2023 Slovenia floods]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Sava v Tacnu 4. avgusta ob 16h.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
In August 2023, major floods occurred in large part of Slovenia and neighbouring areas of Austria and Croatia due to heavy rain. Amongst others, the level of rivers Sava, Mur and Drava was exceptionally high. Several settlements and transport links in Slovene Littoral, Upper Carniola and Slovenian Carinthia were flooded. Due to the amount of rain, the streams in Idrija, Cerkno and Škofja Loka Hills overflowed. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:55, 23 December 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=27933909 --&gt;

== Wikipedia translation of the week: 2025-01 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Uganda Railways Corporation]]'''&lt;br /&gt; &lt;small&gt;''([[:de:Schienenverkehr in Uganda]])&amp;#32;([[:no:Uganda Railways Corporation]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:9620 mit Güterzug.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Uganda Railways Corporation''' (URC) is the parastatal railway of Uganda. It was formed after the breakup of the East African Railways Corporation (EARC) in 1977 when it took over the Ugandan part of the East African railways. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:37, 30 December 2024 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28019313 --&gt;

== Wikipedia translation of the week: 2025-02 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Internment of Japanese Canadians]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Japanese road camp.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
From 1942 to 1949, Canada forcibly relocated and incarcerated over 22,000 Japanese Canadians—comprising over 90% of the total Japanese Canadian population—from British Columbia in the name of &quot;national security&quot;. The majority were Canadian citizens by birth and were targeted based on their ancestry. This decision followed the events of the Japanese Empire's war in the Pacific against the Western Allies, such as the invasion of Hong Kong, the attack on Pearl Harbor in Hawaii, and the Fall of Singapore which led to the Canadian declaration of war on Japan during World War II. Similar to the actions taken against Japanese Americans in neighbouring United States, this forced relocation subjected many Japanese Canadians to government-enforced curfews and interrogations, job and property losses, and forced repatriation to Japan 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 03:56, 6 January 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28070038 --&gt;

== Wikipedia translation of the week: 2025-03 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Christmas seals]]'''&lt;br /&gt; &lt;small&gt;''([[:no:Julemerke]])&amp;#32;([[:ru:Рождественская виньетка]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:1915 US Christmas Seal.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Christmas seals''' are adhesive labels that are similar in appearance to postage stamps that are sold then affixed to mail during the Christmas season to raise funds and awareness for charitable programs. Christmas seals have become particularly associated with lung diseases such as tuberculosis, and with child welfare in general. They were first issued in Denmark beginning in 1904, with Sweden and Iceland following with issues that same year. Thereafter the use of Christmas seals proved to be popular and spread quickly around the world, with 130 countries producing their own issues. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:24, 13 January 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28086717 --&gt;

== Tech News: 2025-03 ==

&lt;section begin=&quot;technews-2025-W03&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/03|Translations]] are available.

'''Weekly highlight'''
* The Single User Login system is being updated over the next few months. This is the system which allows users to fill out the login form on one Wikimedia site and get logged in on all others at the same time. It needs to be updated because of the ways that browsers are increasingly restricting cross-domain cookies. To accommodate these restrictions, login and account creation pages will move to a central domain, but it will still appear to the user as if they are on the originating wiki. The updated code will be enabled this week for users on test wikis. This change is planned to roll out to all users during February and March. See [[mw:Special:MyLanguage/MediaWiki Platform Team/SUL3#Deployment|the SUL3 project page]] for more details and a timeline.

'''Updates for editors'''
* On wikis with [[mw:Special:MyLanguage/Extension:PageAssessments|PageAssessments]] installed, you can now [[mw:Special:MyLanguage/Extension:PageAssessments#Search|filter search results]] to pages in a given WikiProject by using the &lt;code dir=ltr&gt;inproject:&lt;/code&gt; keyword. (These wikis: {{int:project-localized-name-arwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-enwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-enwikivoyage/en}}{{int:comma-separator/en}}{{int:project-localized-name-frwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-huwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-newiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-trwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-zhwiki/en}}) [https://phabricator.wikimedia.org/T378868] 
* One new wiki has been created: a {{int:project-localized-name-group-wikipedia}} in [[d:Q34129|Tigre]] ([[w:tig:|&lt;code&gt;w:tig:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T381377]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:35}} community-submitted {{PLURAL:35|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, there was a bug with updating a user's edit-count after making a rollback edit, which is now fixed. [https://phabricator.wikimedia.org/T382592]

'''Updates for technical contributors'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. Starting the week of January 13, we will begin rerouting [[phab:T374683|some page content endpoints]] from RESTbase to the newer MediaWiki REST API endpoints for all wiki projects. This change was previously available on testwiki and should not affect existing functionality, but active users of the impacted endpoints may raise issues directly to the [[phab:project/view/6931/|MediaWiki Interfaces Team]] in Phabricator if they arise.
* Toolforge tool maintainers can now share their feedback on Toolforge UI, an initiative to provide a web platform that allows creating and managing Toolforge tools through a graphic interface, in addition to existing command-line workflows. This project aims to streamline active maintainers’ tasks, as well as make registration and deployment processes more accessible for new tool creators. The initiative is still at a very early stage, and the Cloud Services team is in the process of collecting feedback from the Toolforge community to help shape the solution to their needs. [[wikitech:Wikimedia Cloud Services team/EnhancementProposals/Toolforge UI|Read more and share your thoughts about Toolforge UI]]. 
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] For tool and library developers who use the OAuth system: The identity endpoint used for [[mw:Special:MyLanguage/OAuth/For Developers#Identifying the user|OAuth 1]] and [[mw:Special:MyLanguage/OAuth/For Developers#Identifying the user 2|OAuth 2]] returned a JSON object with an integer in its &lt;code&gt;sub&lt;/code&gt; field, which was incorrect (the field must always be a string). This has been fixed; the fix will be deployed to Wikimedia wikis on the week of January 13. [https://phabricator.wikimedia.org/T382139]
* Many wikis currently use [[:mw:Parsoid/Parser Unification/Cite CSS|Cite CSS]] to render custom footnote markers in Parsoid output. Starting January 20 these rules will be disabled, but the developers ask you to ''not'' clean up your &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[MediaWiki:Common.css]]&lt;/bdi&gt; until February 20 to avoid issues during the migration. Your wikis might experience some small changes to footnote markers in Visual Editor and when using experimental Parsoid read mode, but if there are changes these are expected to bring the rendering in line with the legacy parser output. [https://phabricator.wikimedia.org/T370027]

'''Meetings and events'''
* The next meeting in the series of [[c:Special:MyLanguage/Commons:WMF support for Commons/Commons community calls|Wikimedia Foundation Community Conversations with the Wikimedia Commons community]] will take place on [[m:Special:MyLanguage/Event:Commons community discussion - 15 January 2025 08:00 UTC|January 15 at 8:00 UTC]] and [[m:Special:MyLanguage/Event:Commons community discussion - 15 January 2025 16:00 UTC|at 16:00 UTC]]. The topic of this call is defining the priorities in tool investment for Commons. Contributors from all wikis, especially users who are maintaining tools for Commons, are welcome to attend.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/03|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W03&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:42, 14 January 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28048614 --&gt;

== Wikipedia translation of the week: 2025-04 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:2010 Nagorno-Karabakh clashes]]'''&lt;br /&gt; &lt;small&gt;''([[:it:Scontri del Nagorno Karabakh del 2010]])&amp;#32;([[:tr:2010 Dağlık Karabağ çatışmaları]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''2010 Nahorno karabakh war''' were a series of exchanges of gunfire that took place on February 18 on the line of contact dividing Azerbaijani and the Karabakh Armenian military forces. Azerbaijan accused the Armenian forces of firing on the Azerbaijani positions near Tap Qaraqoyunlu, Qızıloba, Qapanlı, Yusifcanlı and Cavahirli villages, as well as in uplands of Agdam Rayon with small arms fire including snipers. As a result, three Azerbaijani soldiers were killed and one wounded. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:20, 20 January 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28099770 --&gt;

== Tech News: 2025-04 ==

&lt;section begin=&quot;technews-2025-W04&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/04|Translations]] are available.

'''Updates for editors'''
* Administrators can mass-delete multiple pages created by a user or IP address using [[mw:Special:MyLanguage/Extension:Nuke|Extension:Nuke]]. It previously only allowed deletion of pages created in the last 30 days. It can now delete pages from the last 90 days, provided it is targeting a specific user or IP address. [https://phabricator.wikimedia.org/T380846]
* On [[phab:P72148|wikis that use]] the [[mw:Special:MyLanguage/Help:Patrolled edits|Patrolled edits]] feature, when the rollback feature is used to revert an unpatrolled page revision, that revision will now be marked as &quot;manually patrolled&quot; instead of &quot;autopatrolled&quot;, which is more accurate. Some editors that use [[mw:Special:MyLanguage/Help:New filters for edit review/Filtering|filters]] on Recent Changes may need to update their filter settings. [https://phabricator.wikimedia.org/T302140]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:31}} community-submitted {{PLURAL:31|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the Visual Editor's &quot;Insert link&quot; feature did not always suggest existing pages properly when an editor started typing, which has now been [[phab:T383497|fixed]].

'''Updates for technical contributors'''
* The Structured Discussion extension (also known as Flow) is being progressively removed from the wikis. This extension is unmaintained and causes issues. It will be replaced by [[mw:Special:MyLanguage/Help:DiscussionTools|DiscussionTools]], which is used on any regular talk page. [[mw:Special:MyLanguage/Structured Discussions/Deprecation#Deprecation timeline|The last group of wikis]] ({{int:project-localized-name-cawikiquote/en}}{{int:comma-separator/en}}{{int:project-localized-name-fiwikimedia/en}}{{int:comma-separator/en}}{{int:project-localized-name-gomwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kabwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ptwikibooks/en}}{{int:comma-separator/en}}{{int:project-localized-name-sewikimedia/en}}) will soon be contacted. If you have questions about this process, please ping [[m:User:Trizek (WMF)|Trizek (WMF)]] at your wiki. [https://phabricator.wikimedia.org/T380912]
* The latest quarterly [[mw:Technical_Community_Newsletter/2025/January|Technical Community Newsletter]] is now available. This edition includes: updates about services from the Data Platform Engineering teams, information about Codex from the Design System team, and more.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/04|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W04&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:37, 21 January 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28129769 --&gt;

== Wikipedia translation of the week: 2025-05 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Jinnah's birthday]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Yorkstatue.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Jinnah's Birthday''', officially Quaid-e-Azam Day and sometimes known as Quaid Day, is a public holiday in Pakistan observed annually on 25 December to celebrate the birthday of the founder of Pakistan, Muhammad Ali Jinnah, known as Quaid-i-Azam (&quot;Great Leader&quot;). A major holiday, commemorations for Jinnah began during his lifetime in 1942, and have continued ever since. The event is primarily observed by the government and the citizens of the country where the national flag is hoisted at major architectural structures such as private and public buildings, particularly at the top of Quaid-e-Azam House in Karachi. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:30, 27 January 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28156501 --&gt;

== Tech News: 2025-05 ==

&lt;section begin=&quot;technews-2025-W05&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/05|Translations]] are available.

'''Weekly highlight'''
* Patrollers and admins - what information or context about edits or users could help you to make patroller or admin decisions more quickly or easily? The Wikimedia Foundation wants to hear from you to help guide its upcoming annual plan. Please consider sharing your thoughts on this and [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Product &amp; Technology OKRs|13 other questions]] to shape the technical direction for next year.

'''Updates for editors'''
* iOS Wikipedia App users worldwide can now access a [[mw:Special:MyLanguage/Wikimedia Apps/Team/iOS/Personalized Wikipedia Year in Review/How your data is used|personalized Year in Review]] feature, which provides insights based on their reading and editing history on Wikipedia. This project is part of a broader effort to help welcome new readers as they discover and interact with encyclopedic content.
* [[File:Octicons-gift.svg|12px|link=|class=skin-invert|Wishlist item]] Edit patrollers now have a new feature available that can highlight potentially problematic new pages. When a page is created with the same title as a page which was previously deleted, a tag ('Recreated') will now be added, which users can filter for in [[{{#special:RecentChanges}}]] and [[{{#special:NewPages}}]]. [https://phabricator.wikimedia.org/T56145]
* Later this week, there will be a new warning for editors if they attempt to create a redirect that links to another redirect (a [[mw:Special:MyLanguage/Help:Redirects#Double redirects|double redirect]]). The feature will recommend that they link directly to the second redirect's target page. Thanks to the user SomeRandomDeveloper for this improvement. [https://phabricator.wikimedia.org/T326056]
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Wikimedia wikis allow [[w:en:WebAuthn|WebAuthn]]-based second factor checks (such as hardware tokens) during login, but the feature is [[m:Community Wishlist Survey 2023/Miscellaneous/Fix security key (WebAuthn) support|fragile]] and has very few users. The MediaWiki Platform team is temporarily disabling adding new WebAuthn keys, to avoid interfering with the rollout of [[mw:MediaWiki Platform Team/SUL3|SUL3]] (single user login version 3). Existing keys are unaffected. [https://phabricator.wikimedia.org/T378402]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:30}} community-submitted {{PLURAL:30|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''

* For developers that use the [[wikitech:Data Platform/Data Lake/Edits/MediaWiki history dumps|MediaWiki History dumps]]: The Data Platform Engineering team has added a couple of new fields to these dumps, to support the [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|Temporary Accounts]] initiative. If you maintain software that reads those dumps, please review your code and the updated documentation, since the order of the fields in the row will change. There will also be one field rename: in the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;mediawiki_user_history&lt;/code&gt;&lt;/bdi&gt; dump, the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;anonymous&lt;/code&gt;&lt;/bdi&gt; field will be renamed to &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;is_anonymous&lt;/code&gt;&lt;/bdi&gt;. The changes will take effect with the next release of the dumps in February. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/LKMFDS62TXGDN6L56F4ABXYLN7CSCQDI/] 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/05|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W05&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:15, 27 January 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28149374 --&gt;

== Wikipedia translation of the week: 2025-06 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:French conquest of Corsica]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Bataille de Ponte Novu.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''French conquest of Corsica''' was a successful expedition by French forces of the Kingdom of France under Comte de Vaux, against Corsican forces under Pasquale Paoli of the Corsican Republic. The expedition was launched in May 1768, in the aftermath of the Seven Years' War. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 12:20, 3 February 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28200320 --&gt;

== Tech News: 2025-06 ==

&lt;section begin=&quot;technews-2025-W06&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/06|Translations]] are available.

'''Updates for editors'''
* Editors who use the &quot;Special characters&quot; editing-toolbar menu can now see the 32 special characters you have used most recently, across editing sessions on that wiki. This change should help make it easier to find the characters you use most often. The feature is in both the 2010 wikitext editor and VisualEditor. [https://phabricator.wikimedia.org/T110722]
* Editors using the 2010 wikitext editor can now create sublists with correct indentation by selecting the line(s) you want to indent and then clicking the toolbar buttons.[https://phabricator.wikimedia.org/T380438] You can now also insert &lt;code&gt;&lt;nowiki&gt;&lt;code&gt;&lt;/nowiki&gt;&lt;/code&gt; tags using a new toolbar button.[https://phabricator.wikimedia.org/T383010] Thanks to user stjn for these improvements.
* Help is needed to ensure the [[mw:Special:MyLanguage/Citoid/Enabling Citoid on your wiki|citation generator]] works properly on each wiki.
** (1) Administrators should update the local versions of the page &lt;code dir=ltr&gt;MediaWiki:Citoid-template-type-map.json&lt;/code&gt; to include entries for &lt;code dir=ltr&gt;preprint&lt;/code&gt;, &lt;code dir=ltr&gt;standard&lt;/code&gt;, and &lt;code dir=ltr&gt;dataset&lt;/code&gt;; Here are example diffs to replicate [https://en.wikipedia.org/w/index.php?title=MediaWiki%3ACitoid-template-type-map.json&amp;diff=1189164774&amp;oldid=1165783565 for 'preprint'] and [https://en.wikipedia.org/w/index.php?title=MediaWiki%3ACitoid-template-type-map.json&amp;diff=1270832208&amp;oldid=1270828390 for 'standard' and 'dataset'].
** (2.1) If the citoid map in the citation template used for these types of references is missing, [[mediawikiwiki:Citoid/Enabling Citoid on your wiki#Step 2.a: Create a 'citoid' maps value for each citation template|one will need to be added]]. (2.2) If the citoid map does exist, the TemplateData will need to be updated to include new field names. Here are example updates [https://en.wikipedia.org/w/index.php?title=Template%3ACitation%2Fdoc&amp;diff=1270829051&amp;oldid=1262470053 for 'preprint'] and [https://en.wikipedia.org/w/index.php?title=Template%3ACitation%2Fdoc&amp;diff=1270831369&amp;oldid=1270829480 for 'standard' and 'dataset']. The new fields that may need to be supported are &lt;code dir=ltr&gt;archiveID&lt;/code&gt;, &lt;code dir=ltr&gt;identifier&lt;/code&gt;, &lt;code dir=ltr&gt;repository&lt;/code&gt;, &lt;code dir=ltr&gt;organization&lt;/code&gt;, &lt;code dir=ltr&gt;repositoryLocation&lt;/code&gt;, &lt;code dir=ltr&gt;committee&lt;/code&gt;, and &lt;code dir=ltr&gt;versionNumber&lt;/code&gt;. [https://phabricator.wikimedia.org/T383666]
* One new wiki has been created: a {{int:project-localized-name-group-wikipedia/en}} in [[d:Q15637215|Central Kanuri]] ([[w:knc:|&lt;code&gt;w:knc:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T385181]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the [[mediawikiwiki:Special:MyLanguage/Help:Extension:Wikisource/Wikimedia OCR|OCR (optical character recognition) tool]] used for Wikisource now supports a new language, Church Slavonic. [https://phabricator.wikimedia.org/T384782]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/06|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W06&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:09, 4 February 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28203495 --&gt;

== Wikipedia translation of the week: 2025-07 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Assassination of Spencer Perceval]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:PercevalShooting.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
On 11 May 1812, at about 5:15 pm, Spencer Perceval, the prime minister of the United Kingdom of Great Britain and Ireland, was shot dead in the lobby of the House of Commons by John Bellingham, a Liverpool merchant with a grievance against the government. Bellingham was detained; four days after the murder, he was tried, convicted and sentenced to death. He was hanged at Newgate Prison on 18 May, one week after the assassination and one month before the start of the War of 1812. Perceval remains the sole British prime minister to have been assassinated. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:18, 10 February 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28200320 --&gt;

== Tech News: 2025-07 ==

&lt;section begin=&quot;technews-2025-W07&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/07|Translations]] are available.

'''Weekly highlight'''

* The Product and Technology Advisory Council (PTAC) has published [[m:Special:MyLanguage/Product and Technology Advisory Council/February 2025 draft PTAC recommendation for feedback|a draft of their recommendations]] for the Wikimedia Foundation's Product and Technology department. They have recommended focusing on [[m:Special:MyLanguage/Product and Technology Advisory Council/February 2025 draft PTAC recommendation for feedback/Mobile experiences|mobile experiences]], particularly contributions. They request community [[m:Talk:Product and Technology Advisory Council/February 2025 draft PTAC recommendation for feedback|feedback at the talk page]] by 21 February.

'''Updates for editors'''
* The &quot;Special pages&quot; portlet link will be moved from the &quot;Toolbox&quot; into the &quot;Navigation&quot; section of the main menu's sidebar by default. This change is because the Toolbox is intended for tools relating to the current page, not tools relating to the site, so the link will be more logically and consistently located. To modify this behavior and update CSS styling, administrators can follow the instructions at [[phab:T385346|T385346]]. [https://phabricator.wikimedia.org/T333211]
* As part of this year's work around improving the ways readers discover content on the wikis, the Web team will be running an experiment with a small number of readers that displays some suggestions for related or interesting articles within the search bar. Please check out [[mw:Special:MyLanguage/Reading/Web/Content Discovery Experiments#Experiment 1: Display article recommendations in more prominent locations, search|the project page]] for more information.
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Template editors who use TemplateStyles can now customize output for users with specific accessibility needs by using accessibility related media queries (&lt;code dir=ltr&gt;[https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion prefers-reduced-motion]&lt;/code&gt;, &lt;code dir=ltr&gt;[https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-transparency prefers-reduced-transparency]&lt;/code&gt;, &lt;code dir=ltr&gt;[https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-contrast prefers-contrast]&lt;/code&gt;, and &lt;code dir=ltr&gt;[https://developer.mozilla.org/en-US/docs/Web/CSS/@media/forced-colors forced-colors]&lt;/code&gt;). Thanks to user Bawolff for these improvements. [https://phabricator.wikimedia.org/T384175]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:22}} community-submitted {{PLURAL:22|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the global blocks log will now be shown directly on the {{#special:CentralAuth}} page, similarly to global locks, to simplify the workflows for stewards. [https://phabricator.wikimedia.org/T377024]

'''Updates for technical contributors'''
* Wikidata [[d:Special:MyLanguage/Help:Default values for labels and aliases|now supports a special language as a &quot;default for all languages&quot;]] for labels and aliases. This is to avoid excessive duplication of the same information across many languages. If your Wikidata queries use labels, you may need to update them as some existing labels are getting removed. [https://phabricator.wikimedia.org/T312511]
* The function &lt;code dir=&quot;ltr&quot;&gt;getDescription&lt;/code&gt; was invoked on every Wiki page read and accounts for ~2.5% of a page's total load time. The calculated value will now be cached, reducing load on Wikimedia servers. [https://phabricator.wikimedia.org/T383660]
* As part of the RESTBase deprecation [[mw:RESTBase/deprecation|effort]], the &lt;code dir=&quot;ltr&quot;&gt;/page/related&lt;/code&gt; endpoint has been blocked as of February 6, 2025, and will be removed soon. This timeline was chosen to align with the deprecation schedules for older Android and iOS versions. The stable alternative is the &quot;&lt;code dir=&quot;ltr&quot;&gt;morelike&lt;/code&gt;&quot; action API in MediaWiki, and [[gerrit:c/mediawiki/services/mobileapps/+/982154/13/pagelib/src/transform/FooterReadMore.js|a migration example]] is available. The MediaWiki Interfaces team [[phab:T376297|can be contacted]] for any questions. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/GFC2IJO7L4BWO3YTM7C5HF4MCCBE2RJ2/]

'''In depth'''

* The latest quarterly [[mw:Special:MyLanguage/Wikimedia Language and Product Localization/Newsletter/2025/January|Language and Internationalization newsletter]] is available. It includes: Updates about the &quot;Contribute&quot; menu; details on some of the newest language editions of Wikipedia; details on new languages supported by the MediaWiki interface; updates on the Community-defined lists feature; and more. 
* The latest [[mw:Extension:Chart/Project/Updates#January 2025: Better visibility into charts and tabular data usage|Chart Project newsletter]] is available. It includes updates on the progress towards bringing better visibility into global charts usage and support for categorizing pages in the Data namespace on Commons.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/07|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W07&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:12, 11 February 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28231022 --&gt;

== Wikipedia translation of the week: 2025-08 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:2010 Malagasy constitutional referendum]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
A constitutional referendum was held in Madagascar on 17 November 2010, in which voters approved a proposal for the state's fourth Constitution. The Malagasy people were asked to answer &quot;Yes&quot; or &quot;No&quot; to the proposed new constitution, which was considered to help consolidate Andry Rajoelina's grip on power. At the time of the referendum, Rajoelina headed the governing Highest Transitional Authority (HAT), an interim junta established following the military-backed coup d'état against then President Marc Ravalomanana in March 2009. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:21, 17 February 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28245290 --&gt;

== Tech News: 2025-08 ==

&lt;section begin=&quot;technews-2025-W08&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/08|Translations]] are available.

'''Weekly highlight'''
* Communities using growth tools can now showcase one event on the &lt;code&gt;{{#special:Homepage}}&lt;/code&gt; for newcomers. This feature will help newcomers to be informed about editing activities they can participate in. Administrators can create a new event to showcase at &lt;code&gt;{{#special:CommunityConfiguration}}&lt;/code&gt;. To learn more about this feature, please read [[diffblog:2025/02/12/community-updates-module-connecting-newcomers-to-your-initiatives/|the Diff post]], have a look [[mw:Special:MyLanguage/Help:Growth/Tools/Community updates module|at the documentation]], or contact [[mw:Talk:Growth|the Growth team]].

'''Updates for editors'''
[[File:Page Frame Features on desktop.png|thumb|Highlighted talk pages improvements]]
* Starting next week, talk pages at these wikis – {{int:project-localized-name-eswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-frwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-itwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-jawiki/en}} – will get [[diffblog:2024/05/02/making-talk-pages-better-for-everyone/|a new design]]. This change was extensively tested as a Beta feature and is the last step of [[mw:Special:MyLanguage/Talk pages project/Feature summary|talk pages improvements]]. [https://phabricator.wikimedia.org/T379102]
* You can now navigate to view a redirect page directly from its action pages, such as the history page. Previously, you were forced to first go to the redirect target. This change should help editors who work with redirects a lot. Thanks to user stjn for this improvement. [https://phabricator.wikimedia.org/T5324]
* When a Cite reference is reused many times, wikis currently show either numbers like &quot;1.23&quot; or localized alphabetic markers like &quot;a b c&quot; in the reference list. Previously, if there were so many reuses that the alphabetic markers were all used, [[MediaWiki:Cite error references no backlink label|an error message]] was displayed.  As part of the work to [[phab:T383036|modernize Cite customization]], these errors will no longer be shown and instead the backlinks will fall back to showing numeric markers like &quot;1.23&quot; once the alphabetic markers are all used.
* The log entries for each change to an editor's user-groups are now clearer by specifying exactly what has changed, instead of the plain before and after listings. Translators can [[phab:T369466|help to update the localized versions]]. Thanks to user Msz2001 for these improvements.
* A new filter has been added to the [[{{#special:Nuke}}]] tool, which allows administrators to mass delete pages, to enable users to filter for pages in a range of page sizes (in bytes). This allows, for example, deleting pages only of a certain size or below. [https://phabricator.wikimedia.org/T378488]
* Non-administrators can now check which pages are able to be deleted using the [[{{#special:Nuke}}]] tool. Thanks to user MolecularPilot for this and the previous improvements. [https://phabricator.wikimedia.org/T376378]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:25}} community-submitted {{PLURAL:25|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a bug was fixed in the configuration for the AV1 video file format, which enables these files to play again. [https://phabricator.wikimedia.org/T382193]

'''Updates for technical contributors'''
* Parsoid Read Views is going to be rolling out to most Wiktionaries over the next few weeks, following the successful transition of Wikivoyage to Parsoid Read Views last year. For more information, see the [[mw:Special:MyLanguage/Parsoid/Parser Unification|Parsoid/Parser Unification]] project page. [https://phabricator.wikimedia.org/T385923][https://phabricator.wikimedia.org/T371640]
* Developers of tools that run on-wiki should note that &lt;code dir=ltr&gt;mw.Uri&lt;/code&gt; is deprecated. Tools requiring &lt;code dir=ltr&gt;mw.Uri&lt;/code&gt; must explicitly declare &lt;code dir=ltr&gt;mediawiki.Uri&lt;/code&gt; as a ResourceLoader dependency, and should migrate to the browser native &lt;code dir=ltr&gt;URL&lt;/code&gt; API soon. [https://phabricator.wikimedia.org/T384515]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/08|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W08&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:17, 17 February 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28275610 --&gt;

== Wikipedia translation of the week: 2025-09 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Cooler Heads Coalition]]'''&lt;br /&gt; &lt;small&gt;''([[:de:Cooler Heads Coalition]])&amp;#32;([[:fr:Cooler Heads Coalition]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Cooler Heads Coalition''' is a politically conservative &quot;informal and ad-hoc group&quot; in the United States, financed and operated by the Competitive Enterprise Institute. The group, which rejects the scientific consensus on climate change, made efforts to stop the government from addressing climate change. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:23, 24 February 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28300238 --&gt;

== Tech News: 2025-09 ==

&lt;section begin=&quot;technews-2025-W09&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/09|Translations]] are available.

'''Updates for editors'''
* Administrators can now customize how the [[m:Special:MyLanguage/User language|Babel feature]] creates categories using [[{{#special:CommunityConfiguration/Babel}}]]. They can rename language categories, choose whether they should be auto-created, and adjust other settings. [https://phabricator.wikimedia.org/T374348]
* The &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[https://www.wikimedia.org/ wikimedia.org]&lt;/bdi&gt; portal has been updated – and is receiving some ongoing improvements – to modernize and improve the accessibility of our portal pages. It now has better support for mobile layouts, updated wording and links, and better language support. Additionally, all of the Wikimedia project portals, such as &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[https://wikibooks.org wikibooks.org]&lt;/bdi&gt;, now support dark mode when a reader is using that system setting. [https://phabricator.wikimedia.org/T373204][https://phabricator.wikimedia.org/T368221][https://meta.wikimedia.org/wiki/Project_portals]
* One new wiki has been created: a {{int:project-localized-name-group-wiktionary/en}} in [[d:Q33965|Santali]] ([[wikt:sat:|&lt;code&gt;wikt:sat:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T386619]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:30}} community-submitted {{PLURAL:30|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a bug was fixed that prevented clicking on search results in the web-interface for some Firefox for Android phone configurations. [https://phabricator.wikimedia.org/T381289]

'''Meetings and events'''
* The next Language Community Meeting is happening soon, February 28th at [https://zonestamp.toolforge.org/1740751200 14:00 UTC]. This week's meeting will cover: highlights and technical updates on keyboard and tools for the Sámi languages, Translatewiki.net contributions from the Bahasa Lampung community in Indonesia, and technical Q&amp;A. If you'd like to join, simply [[mw:Wikimedia Language and Product Localization/Community meetings#28 February 2025|sign up on the wiki page]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/09|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W09&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:42, 25 February 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28296129 --&gt;

== Wikipedia translation of the week: 2025-10 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:pt:Transmissor de Ondas]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Wave Transmitter]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Esq eletr transm ondas color.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Transmissor de Ondas''' é um equipamento precursor do rádio, desenvolvido por Roberto Landell de Moura na década de 1890, capaz de transmitir áudio via ondas eletromagnéticas, com sua primeira demonstração pública documentada tendo ocorrido no dia 16 de julho de 1899. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:49, 3 March 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28317097 --&gt;

== Tech News: 2025-10 ==

&lt;section begin=&quot;technews-2025-W10&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/10|Translations]] are available.

'''Updates for editors'''
* All logged-in editors using the mobile view can now edit a full page. The &quot;{{int:Minerva-page-actions-editfull}}&quot; link is accessible from the &quot;{{int:minerva-page-actions-overflow}}&quot; menu in the toolbar. This was previously only available to editors using the [[mw:Special:MyLanguage/Reading/Web/Advanced mobile contributions|Advanced mobile contributions]] setting. [https://phabricator.wikimedia.org/T387180]
* Interface administrators can now help to remove the deprecated Cite CSS code matching &quot;&lt;code dir=&quot;ltr&quot;&gt;mw-ref&lt;/code&gt;&quot; from their local &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[MediaWiki:Common.css]]&lt;/bdi&gt;. The list of wikis in need of cleanup, and the code to remove, [https://global-search.toolforge.org/?q=mw-ref%5B%5E-a-z%5D&amp;regex=1&amp;namespaces=8&amp;title=.*css can be found with this global search] and in [https://ace.wikipedia.org/w/index.php?title=MediaWiki:Common.css&amp;oldid=145662#L-139--L-144 this example], and you can learn more about how to help on the [[mw:Parsoid/Parser Unification/Cite CSS|CSS migration project page]]. The Cite footnote markers (&quot;&lt;code dir=&quot;ltr&quot;&gt;[1]&lt;/code&gt;&quot;) are now rendered by [[mw:Special:MyLanguage/Parsoid|Parsoid]], and the deprecated CSS is no longer needed. The CSS for backlinks (&quot;&lt;code dir=&quot;ltr&quot;&gt;mw:referencedBy&lt;/code&gt;&quot;) should remain in place for now. This cleanup is expected to cause no visible changes for readers. Please help to remove this code before March 20, after which the development team will do it for you.
* When editors embed a file (e.g. &lt;code&gt;&lt;nowiki&gt;[[File:MediaWiki.png]]&lt;/nowiki&gt;&lt;/code&gt;) on a page that is protected with cascading protection, the software will no longer restrict edits to the file description page, only to new file uploads.[https://phabricator.wikimedia.org/T24521] In contrast, transcluding a file description page (e.g. &lt;code&gt;&lt;nowiki&gt;{{:File:MediaWiki.png}}&lt;/nowiki&gt;&lt;/code&gt;) will now restrict edits to the page.[https://phabricator.wikimedia.org/T62109]
* When editors revert a file to an earlier version it will now require the same permissions as ordinarily uploading a new version of the file. The software now checks for 'reupload' or 'reupload-own' rights,[https://phabricator.wikimedia.org/T304474] and respects cascading protection.[https://phabricator.wikimedia.org/T140010]
* When administrators are listing pages for deletion with the Nuke tool, they can now also list associated talk pages and redirects for deletion, alongside pages created by the target, rather than needing to manually delete these pages afterwards. [https://phabricator.wikimedia.org/T95797]
* The [[m:Special:MyLanguage/Tech/News/2025/03|previously noted]] update to Single User Login, which will accommodate browser restrictions on cross-domain cookies by moving login and account creation to a central domain, will now roll out to all users during March and April. The team plans to enable it for all new account creation on [[wikitech:Deployments/Train#Tuesday|Group0]] wikis this week. See [[mw:Special:MyLanguage/MediaWiki Platform Team/SUL3#Deployment|the SUL3 project page]] for more details and an updated timeline.
* Since last week there has been a bug that shows some interface icons as black squares until the page has fully loaded. It will be fixed this week. [https://phabricator.wikimedia.org/T387351]
* One new wiki has been created: a {{int:project-localized-name-group-wikipedia/en}} in [[d:Q2044560|Sylheti]] ([[w:syl:|&lt;code&gt;w:syl:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T386441]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:23}} community-submitted {{PLURAL:23|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a bug was fixed with loading images in very old versions of the Firefox browser on mobile. [https://phabricator.wikimedia.org/T386400]

'''Updates for technical contributors'''
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.44/wmf.19|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/10|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W10&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 02:31, 4 March 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28334563 --&gt;

== Wikipedia translation of the week: 2025-11 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Smoky (mascotte olimpica)]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Smoky (Olympic mascot)]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Smoky 1932 Olympic Village Mascot.webp|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Smoky''' (Los Angeles, 1931 o 1932 - Los Angeles, aprile 1934), occasionalmente scritto Smokey, è stato un cane che divenne la mascotte del villaggio olimpico estivo del 1932 e, successivamente, dell'evento generale. Pur non essendo oggi riconosciuto dal CIO, è stato, seppur non in modo ufficiale, la prima mascotte olimpica dei Giochi, oltre che a essere attualmente l'unica a essere stata un animale vero. Le successive edizioni non ebbero mascotte, dovendo aspettare i X Giochi olimpici invernali di Grenoble nel 1968 per ritrovarne una ufficialmente riconosciuta, lo sciatore stilizzato Schuss, allora non considerato ufficiale ma successivamente riconosciuto come tale. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:50, 10 March 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28317097 --&gt;

== Tech News: 2025-11 ==

&lt;section begin=&quot;technews-2025-W11&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/11|Translations]] are available.

'''Updates for editors'''
* Editors who use password managers at multiple wikis may notice changes in the future. The way that our wikis provide information to password managers about reusing passwords across domains has recently been updated, so some password managers might now offer you login credentials that you saved for a different Wikimedia site. Some password managers already did this, and are now doing it for more Wikimedia domains. This is part of the [[mw:Special:MyLanguage/MediaWiki Platform Team/SUL3|SUL3 project]] which aims to improve how our unified login works, and to keep it compatible with ongoing changes to the web-browsers we use. [https://phabricator.wikimedia.org/T385520][https://phabricator.wikimedia.org/T384844]
* The Wikipedia Apps Team is inviting interested users to help improve Wikipedia’s offline and limited internet use. After discussions in [[m:Afrika Baraza|Afrika Baraza]] and the last [[m:Special:MyLanguage/ESEAP Hub/Meetings|ESEAP call]], key challenges like search, editing, and offline access are being explored, with upcoming focus groups to dive deeper into these topics. All languages are welcome, and interpretation will be available. Want to share your thoughts? [[mw:Special:MyLanguage/Wikimedia Apps/Improving Wikipedia Mobile Apps for Offline &amp; Limited Internet Use|Join the discussion]] or email &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;aramadan@wikimedia.org&lt;/bdi&gt;!
* All wikis will be read-only for a few minutes on March 19. This is planned at [https://zonestamp.toolforge.org/1742392800 14:00 UTC]. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.44/wmf.20|MediaWiki]]

'''In depth'''
* The latest quarterly [[mw:Special:MyLanguage/Growth/Newsletters/33|Growth newsletter]] is available. It includes: the launch of the Community Updates module, the most recent changes in Community Configuration, and the upcoming test of in-article suggestions for first-time editors.
* An old API that was previously used in the Android Wikipedia app is being removed at the end of March. There are no current software uses, but users of the app with a version that is older than 6 months by the time of removal (2025-03-31), will no longer have access to the Suggested Edits feature, until they update their app. You can [[diffblog:2025/02/24/sunset-of-wikimedia-recommendation-api/|read more details about this change]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/11|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W11&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:10, 10 March 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28372257 --&gt;

== Wikipedia translation of the week: 2025-12 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Amazonas, o maior rio do mundo]]'''&lt;br /&gt; &lt;small&gt;''([[:pt:Amazonas, o maior rio do mundo]])&amp;#32;([[:es:Amazonas, o maior rio do mundo]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Frame A from Amazonas, o maior rio do mundo.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''Amazonas, o maior rio do mundo''''' (lit. 'Amazon: The Greatest River in the World') is a 1922 Brazilian silent documentary film produced in 1918 by Silvino Santos. It is a black-and-white film that portrays life in the Amazon rainforest. Completed in 1920, it is considered one of the oldest cinematic records of the Amazon. It was presumed lost in 1931 and only rediscovered in 2023 at the Czech Film Archive.

Silvino Santos produced the work over three years using sophisticated cinematic techniques, which led it to be deemed of &quot;immense artistic value&quot; by Le Monde. It has also been described as the &quot;Holy Grail of Brazilian silent cinema&quot; by The Guardian. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:57, 17 March 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28392163 --&gt;

== Tech News: 2025-12 ==

&lt;section begin=&quot;technews-2025-W12&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/12|Translations]] are available.

'''Weekly highlight'''
* Twice a year, around the equinoxes, the Wikimedia Foundation's Site Reliability Engineering (SRE) team performs [[m:Special:MyLanguage/Tech/Server switch|a datacenter server switchover]], redirecting all traffic from one primary server to its backup. This provides reliability in case of a crisis, as we can always fall back on the other datacenter. [http://listen.hatnote.com/ Thanks to the Listen to Wikipedia] tool, you can hear the switchover take place: Before it begins, you'll hear the steady stream of edits; Then, as the system enters a brief read-only phase, the sound stops for a couple of minutes, before resuming after the switchover. You can [[diffblog:2025/03/12/hear-that-the-wikis-go-silent-twice-a-year/|read more about the background and details of this process on the Diff blog]]. If you want to keep an ear out for the next server switchover, listen to the wikis on [https://zonestamp.toolforge.org/1742392800 March 19 at 14:00 UTC].

'''Updates for editors'''

* The [https://test.wikipedia.org/w/index.php?title=Special:ContentTranslation&amp;filter-type=automatic&amp;filter-id=previous-edits&amp;active-list=suggestions&amp;from=en&amp;to=es improved Content Translation tool dashboard] is now available in [[phab:T387820|10 Wikipedias]] and will be available for all Wikipedias [[phab:T387821|soon]]. With [[mw:Special:MyLanguage/Content translation#Improved translation experience|the unified dashboard]], desktop users can now: Translate new sections of an article; Discover and access topic-based [https://ig.m.wikipedia.org/w/index.php?title=Special:ContentTranslation&amp;active-list=suggestions&amp;from=en&amp;to=ig&amp;filter-type=automatic&amp;filter-id=previous-edits article suggestion filters] (initially available only for mobile device users); Discover and access the [[mw:Special:MyLanguage/Translation suggestions: Topic-based &amp; Community-defined lists|Community-defined lists]] filter, also known as &quot;Collections&quot;, from wiki-projects and campaigns.
* On Wikimedia Commons, a [[c:Commons:WMF support for Commons/Upload Wizard Improvements#Improve category selection|new system to select the appropriate file categories]] has been introduced: if a category has one or more subcategories, users will be able to click on an arrow that will open the subcategories directly within the form, and choose the correct one. The parent category name will always be shown on top, and it will always be possible to come back to it. This should decrease the amount of work for volunteers in fixing/creating new categories. The change is also available on mobile. These changes are part of planned improvements to the UploadWizard.
* The Community Tech team is seeking wikis to join a pilot for the [[m:Special:MyLanguage/Community Wishlist Survey 2023/Multiblocks|Multiblocks]] feature and a refreshed Special:Block page in late March. Multiblocks enables administrators to impose multiple different types of blocks on the same user at the same time. If you are an admin or steward and would like us to discuss joining the pilot with your community, please leave a message on the [[m:Talk:Community Wishlist Survey 2023/Multiblocks|project talk page]].
* Starting March 25, the Editing team will test a new feature for Edit Check at [[phab:T384372|12 Wikipedias]]: [[mw:Special:MyLanguage/Help:Edit check#Multi-check|Multi-Check]]. Half of the newcomers on these wikis will see all [[mw:Special:MyLanguage/Help:Edit check#ref|Reference Checks]] during their edit session, while the other half will continue seeing only one. The goal of this test is to see if users are confused or discouraged when shown multiple Reference Checks (when relevant) within a single editing session. At these wikis, the tags used on edits that show References Check will be simplified, as multiple tags could be shown within a single edit. Changes to the tags are documented [[phab:T373949|on Phabricator]]. [https://phabricator.wikimedia.org/T379131]
* The [[m:Special:MyLanguage/Global reminder bot|Global reminder bot]], which is a service for notifying users that their temporary user-rights are about to expire, now supports using the localized name of the user-rights group in the message heading. Translators can see the [[m:Global reminder bot/Translation|listing of existing translations and documentation]] to check if their language needs updating or creation.
* The [[Special:GlobalPreferences|GlobalPreferences]] gender setting, which is used for how the software should refer to you in interface messages, now works as expected by overriding the local defaults. [https://phabricator.wikimedia.org/T386584]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:26}} community-submitted {{PLURAL:26|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the Wikipedia App for Android had a bug fixed for when a user is browsing and searching in multiple languages. [https://phabricator.wikimedia.org/T379777]

'''Updates for technical contributors'''
* Later this week, the way that Codex styles are loaded will be changing. There is a small risk that this may result in unstyled interface message boxes on certain pages. User generated content (e.g. templates) is not impacted. Gadgets may be impacted. If you see any issues [[phab:T388847|please report them]]. See the linked task for details, screenshots, and documentation on how to fix any affected gadgets.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.44/wmf.21|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/12|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W12&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:48, 17 March 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28412594 --&gt;

== Wikipedia translation of the week: 2025-13 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Ali of the Eretnids]]'''&lt;br /&gt; &lt;small&gt;''([[:tr:Alaaddin Ali Bey]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Ala al-Din Ali''' (January 1353 – August 1380) was the third Sultan of the Eretnids ruling from 1366 until his death. He inherited the throne at a very early age and was removed from administrative matters. He was characterized as particularly keen on personal pleasures, which later discredited his authority. During his rule, emirs under the Eretnids enjoyed considerable autonomy, and the state continued to shrink as neighboring powers captured several towns. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:59, 24 March 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28433698 --&gt;

== Tech News: 2025-13 ==

&lt;section begin=&quot;technews-2025-W13&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/13|Translations]] are available.

'''Weekly highlight'''
* The Wikimedia Foundation is seeking your feedback on the [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Product &amp; Technology OKRs|drafts of the objectives and key results that will shape the Foundation's Product and Technology priorities]] for the next fiscal year (starting in July). The objectives are broad high-level areas, and the key-results are measurable ways to track the success of their objectives. Please share your feedback on the talkpage, in any language, ideally before the end of April.

'''Updates for editors'''
* The [[mw:Special:MyLanguage/Help:Extension:CampaignEvents|CampaignEvents extension]] will be released to multiple wikis (see [[m:Special:MyLanguage/CampaignEvents/Deployment status#Global Deployment Plan|deployment plan]] for details) in April 2025, and the team has begun the process of engaging communities on the identified wikis. The extension provides tools to organize, manage, and promote collaborative activities (like events, edit-a-thons, and WikiProjects) on the wikis. The extension has three tools: [[m:Special:MyLanguage/Event Center/Registration|Event Registration]], [[m:Special:MyLanguage/CampaignEvents/Collaboration list|Collaboration List]], and [[m:Special:MyLanguage/Campaigns/Foundation Product Team/Invitation list|Invitation Lists]]. It is currently on 13 Wikipedias, including English Wikipedia, French Wikipedia, and Spanish Wikipedia, as well as Wikidata. Questions or requests can be directed to the [[mw:Help talk:Extension:CampaignEvents|extension talk page]] or in Phabricator (with &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;white-space: nowrap;&quot;&gt;#campaigns-product-team&lt;/bdi&gt; tag).
* Starting the week of March 31st, wikis will be able to set which user groups can view private registrants in [[m:Special:MyLanguage/Event Center/Registration|Event Registration]], as part of the [[mw:Special:MyLanguage/Help:Extension:CampaignEvents|CampaignEvents]] extension. By default, event organizers and the local wiki admins will be able to see private registrants. This is a change from the current behavior, in which only event organizers can see private registrants. Wikis can change the default setup by [[m:Special:MyLanguage/Requesting wiki configuration changes|requesting a configuration change]] in Phabricator (and adding the &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;white-space: nowrap;&quot;&gt;#campaigns-product-team&lt;/bdi&gt; tag). Participants of past events can cancel their registration at any time.
* Administrators at wikis that have a customized &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[MediaWiki:Sidebar]]&lt;/bdi&gt; should check that it contains an entry for the {{int:specialpages}} listing. If it does not, they should add it using &lt;code dir=ltr style=&quot;white-space: nowrap;&quot;&gt;* specialpages-url|specialpages&lt;/code&gt;. Wikis with a default sidebar will see the link moved from the page toolbox into the sidebar menu in April. [https://phabricator.wikimedia.org/T388927]
* The Minerva skin (mobile web) combines both Notice and Alert notifications within the bell icon ([[File:OOjs UI icon bell.svg|16px|link=|class=skin-invert]]). There was a long-standing bug where an indication for new notifications was only shown if you had unseen Alerts. This bug is now fixed. In the future, Minerva users will notice a counter atop the bell icon when you have 1 or more unseen Notices and/or Alerts. [https://phabricator.wikimedia.org/T344029]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:23}} community-submitted {{PLURAL:23|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* VisualEditor has introduced a [[mw:VisualEditor/Hooks|new client-side hook]] for developers to use when integrating with the VisualEditor target lifecycle. This hook should replace the existing lifecycle-related hooks, and be more consistent between different platforms. In addition, the new hook will apply to uses of VisualEditor outside of just full article editing, allowing gadgets to interact with the editor in DiscussionTools as well. The Editing Team intends to deprecate and eventually remove the old lifecycle hooks, so any use cases that this new hook does not cover would be of interest to them and can be [[phab:T355555|shared in the task]].
* Developers who use the &lt;code dir=ltr&gt;mw.Api&lt;/code&gt; JavaScript library, can now identify the tool using it with the &lt;code dir=ltr&gt;userAgent&lt;/code&gt; parameter: &lt;code dir=ltr&gt;var api = new mw.Api( { userAgent: 'GadgetNameHere/1.0.1' } );&lt;/code&gt;. If you maintain a gadget or user script, please set a user agent, because it helps with library and server maintenance and with differentiating between legitimate and illegitimate traffic. [https://phabricator.wikimedia.org/T373874][https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_User-Agent_Policy]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.44/wmf.22|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/13|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W13&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:43, 24 March 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28443127 --&gt;

== Wikipedia translation of the week: 2025-14 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Chilembwe uprising]]'''&lt;br /&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Chilembwe supporters being led to be executed (cropped).jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Chilembwe uprising''' was a rebellion against British colonial rule in Nyasaland (modern-day Malawi) which took place in January 1915. It was led by John Chilembwe, an American-educated Baptist minister. Based around his church in the village of Mbombwe in the south-east of the colony, the leaders of the revolt were mainly from an emerging black middle class. They were motivated by grievances against the British colonial system, which included forced labour, racial discrimination and new demands imposed on the African population following the outbreak of World War I. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 03:52, 31 March 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28454663 --&gt;

== Tech News: 2025-14 ==

&lt;section begin=&quot;technews-2025-W14&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/14|Translations]] are available.

'''Updates for editors'''
* The Editing team is working on a new [[mw:Special:MyLanguage/Edit Check|Edit check]]: [[mw:Special:MyLanguage/Edit check#26 March 2025|Peacock check]]. This check's goal is to identify non-neutral terms while a user is editing a wikipage, so that they can be informed that their edit should perhaps be changed before they publish it. This project is at the early stages, and the team is looking for communities' input: [[phab:T389445|in this Phabricator task]], they are gathering on-wiki policies, templates used to tag non-neutral articles, and the terms (jargon and keywords) used in edit summaries for the languages they are currently researching. You can participate by editing the table on Phabricator, commenting on the task, or directly messaging [[m:user:Trizek (WMF)|Trizek (WMF)]].
* [[mw:Special:MyLanguage/MediaWiki Platform Team/SUL3|Single User Login]] has now been updated on all wikis to move login and account creation to a central domain. This makes user login compatible with browser restrictions on cross-domain cookies, which have prevented users of some browsers from staying logged in.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:35}} community-submitted {{PLURAL:35|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* Starting on March 31st, the MediaWiki Interfaces team will begin a limited release of generated OpenAPI specs and a SwaggerUI-based sandbox experience for [[mw:Special:MyLanguage/API:REST API|MediaWiki REST APIs]]. They invite developers from a limited group of non-English Wikipedia communities (Arabic, German, French, Hebrew, Interlingua, Dutch, Chinese) to review the documentation and experiment with the sandbox in their preferred language. In addition to these specific Wikipedia projects, the sandbox and OpenAPI spec will be available on the [[testwiki:Special:RestSandbox|on the test wiki REST Sandbox special page]] for developers with English as their preferred language. During the preview period, the MediaWiki Interfaces Team also invites developers to [[mw:MediaWiki Interfaces Team/Feature Feedback/REST Sandbox|share feedback about your experience]]. The preview will last for approximately 2 weeks, after which the sandbox and OpenAPI specs will be made available across all wiki projects.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.44/wmf.23|MediaWiki]]

'''In depth'''
* Sometimes a small, [[gerrit:c/operations/cookbooks/+/1129184|one line code change]] can have great significance: in this case, it means that for the first time in years we're able to run all of the stack serving &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[http://maps.wikimedia.org/ maps.wikimedia.org]&lt;/bdi&gt; - a host dedicated to serving our wikis and their multi-lingual maps needs - from a single core datacenter, something we test every time we perform a [[m:Special:MyLanguage/Tech/Server switch|datacenter switchover]]. This is important because it means that in case one of our datacenters is affected by a catastrophe, we'll still be able to serve the site. This change is the result of [[phab:T216826|extensive work]] by two developers on porting the last component of the maps stack over to [[w:en:Kubernetes|kubernetes]], where we can allocate resources more efficiently than before, thus we're able to withstand more traffic in a single datacenter. This work involved a lot of complicated steps because this software, and the software libraries it uses, required many long overdue upgrades. This type of work makes the Wikimedia infrastructure more sustainable.

'''Meetings and events'''
* [[mw:Special:MyLanguage/MediaWiki Users and Developers Workshop Spring 2025|MediaWiki Users and Developers Workshop Spring 2025]] is happening in Sandusky, USA, and online, from 14–16 May 2025. The workshop will feature discussions around the usage of MediaWiki software by and within companies in different industries and will inspire and onboard new users. Registration and presentation signup is now available at the workshop's website.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/14|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W14&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:06, 1 April 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28473566 --&gt;

== Wikipedia translation of the week: 2025-15 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:1930 Bago earthquake]]'''&lt;br /&gt; &lt;small&gt;''([[:my:၁၉၃၀ ပဲခူးငလျင်]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Thiao Mueang Phama (1955, p. 165).jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
An earthquake affected Myanmar on 5 May 1930 with a moment magnitude (Mw ) 7.4. The shock occurred 35 km (22 mi) beneath the surface with a maximum Rossi–Forel intensity of IX (Devastating tremor). The earthquake was the result of rupture along a 131 km (81 mi) segment of the Sagaing Fault—a major strike-slip fault that runs through the country. Extensive damage was reported in the southern part of the country, particularly in Bago and Yangon, where buildings collapsed and fires erupted. At least 550, and possibly up to 7,000 people were killed. A moderate tsunami struck the Burmese coast which caused minor damage to ships and a port. It was felt for over 570,000 km2 (220,000 sq mi) and as far as Shan State and Thailand. The mainshock was followed by many aftershocks; several were damaging. The December earthquake was similarly sized which also occurred along the Sagaing Fault. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:54, 7 April 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28454663 --&gt;

== Tech News: 2025-15 ==

&lt;section begin=&quot;technews-2025-W15&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/15|Translations]] are available.

'''Updates for editors'''
* From now on, [[m:Special:MyLanguage/Interface administrators|interface admins]] and [[m:Special:MyLanguage/Central notice administrators|centralnotice admins]] are technically required to enable [[m:Special:MyLanguage/Help:Two-factor authentication|two-factor authentication]] before they can use their privileges. In the future this might be expanded to more groups with advanced user-rights. [https://phabricator.wikimedia.org/T150898]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:20}} community-submitted {{PLURAL:20|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* The Design System Team is preparing to release the next major version of Codex (v2.0.0) on April 29. Editors and developers who use CSS from Codex should see the [[mw:Codex/Release Timeline/2.0|2.0 overview documentation]], which includes guidance related to a few of the breaking changes such as &lt;code dir=ltr style=&quot;white-space: nowrap;&quot;&gt;font-size&lt;/code&gt;, &lt;code dir=ltr style=&quot;white-space: nowrap;&quot;&gt;line-height&lt;/code&gt;, and &lt;code dir=ltr style=&quot;white-space: nowrap;&quot;&gt;size-icon&lt;/code&gt;.
* The results of the [[mw:Developer Satisfaction Survey/2025|Developer Satisfaction Survey (2025)]]  are now available. Thank you to all participants. These results help the Foundation decide what to work on next and to review what they recently worked on.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.44/wmf.24|MediaWiki]]

'''Meetings and events'''
* The [[mw:Special:MyLanguage/Wikimedia Hackathon 2025|2025 Wikimedia Hackathon]] will take place in Istanbul, Turkey, between 2–4 May. Registration for attending the in-person event will close on 13 April. Before registering, please note the potential need for a [https://www.mfa.gov.tr/turkish-representations.en.mfa visa] or [https://www.mfa.gov.tr/visa-information-for-foreigners.en.mfa e-visa] to enter the country.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/15|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W15&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 18:53, 7 April 2025 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28507470 --&gt;

== Wikipedia translation of the week: 2025-16 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Museum of Zoology of the University of São Paulo]]'''&lt;br /&gt; &lt;small&gt;''([[:pt:Museu de Zoologia da Universidade de São Paulo]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Museu de Zoologia da USP 02.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Museum of Zoology of the University of São Paulo''' (Portuguese: Museu de Zoologia da Universidade de São Paulo, abbreviated MZUSP) is a public natural history museum located in the historic Ipiranga district of São Paulo, Brazil. The MZUSP is an educational and research institution that is part of the University of São Paulo. The museum began at the end of the 19th century as part of the Museu Paulista; in 1941, it moved into a dedicated building. In 1969 the museum became a part of the University of São Paulo, receiving its current name. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:27, 14 April 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28454663 --&gt;

== Tech News: 2025-16 ==

&lt;section begin=&quot;technews-2025-W16&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/16|Translations]] are available.

'''Weekly highlight'''
* Later this week, the default thumbnail size will be increased from 220px to 250px. This changes how pages are shown in all wikis and has been requested by some communities for many years, but wasn't previously possible due to technical limitations. [https://phabricator.wikimedia.org/T355914]
* File thumbnails are now stored in discrete sizes. If a page specifies a thumbnail size that's not among the standard sizes (20, 40, 60, 120, 250, 330, 500, 960), then MediaWiki will pick the closest larger thumbnail size but will tell the browser to downscale it to the requested size. In these cases, nothing will change visually but users might load slightly larger images. If it doesn't matter which thumbnail size is used in a page, please pick one of the standard sizes to avoid the extra in-browser down-scaling step. [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Images#Thumbnail_sizes][https://phabricator.wikimedia.org/T355914]

'''Updates for editors'''
* The Wikimedia Foundation are working on a system called [[m:Edge Uniques|Edge Uniques]] which will enable [[:w:en:A/B testing|A/B testing]], help protect against [[:w:en:Denial-of-service attack|Distributed denial-of-service attacks]] (DDoS attacks), and make it easier to understand how many visitors the Wikimedia sites have. This is so that they can more efficiently build tools which help readers, and make it easier for readers to find what they are looking for.
* To improve security for users, a small percentage of logins will now require that the account owner input a one-time password [[mw:Special:MyLanguage/Help:Extension:EmailAuth|emailed to their account]]. It is recommended that you [[Special:Preferences#mw-prefsection-personal-email|check]] that the email address on your account is set correctly, and that it has been confirmed, and that you have an email set for this purpose. [https://phabricator.wikimedia.org/T390662]
* &quot;Are you interested in taking a short survey to improve tools used for reviewing or reverting edits on your Wiki?&quot; This question will be [[phab:T389401|asked at 7 wikis starting next week]], on Recent Changes and Watchlist pages. The [[mw:Special:MyLanguage/Moderator Tools|Moderator Tools team]] wants to know more about activities that involve looking at new edits made to your Wikimedia project, and determining whether they adhere to your project's policies.
* On April 15, the full Wikidata graph will no longer be supported on &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;[https://query.wikidata.org/ query.wikidata.org]&lt;/bdi&gt;. After this date, scholarly articles will be available through &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot; style=&quot;white-space:nowrap;&quot;&gt;[https://query-scholarly.wikidata.org/ query-scholarly.wikidata.org]&lt;/bdi&gt;, while the rest of the data hosted on Wikidata will be available through the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;[https://query.wikidata.org/ query.wikidata.org]&lt;/bdi&gt; endpoint. This is part of the scheduled split of the Wikidata Graph, which was [[d:Special:MyLanguage/Wikidata:SPARQL query service/WDQS backend update/September 2024 scaling update|announced in September 2024]]. More information is [[d:Wikidata:SPARQL query service/WDQS graph split|available on Wikidata]].
* The latest quarterly [[m:Special:MyLanguage/Wikimedia Apps/Newsletter/First quarter of 2025|Wikimedia Apps Newsletter]] is now available. It covers updates, experiments, and improvements made to the Wikipedia mobile apps.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:30}} community-submitted {{PLURAL:30|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* The latest quarterly [[mw:Technical Community Newsletter/2025/April|Technical Community Newsletter]] is now available. This edition includes: an invitation for tool maintainers to attend the Toolforge UI Community Feedback Session on April 15th; recent community metrics; and recent technical blog posts.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.44/wmf.25|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/16|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W16&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:25, 15 April 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28540654 --&gt;

== Wikipedia translation of the week: 2025-17 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Fear of crime]]'''&lt;br /&gt; &lt;small&gt;''([[:ar:الخوف من الجريمة]])&amp;#32;([[:it:Criminofobia]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Fear of crime''' refers to the fear of being a victim of crime, which is not necessarily reflective of the actual probability of being such a victim. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:23, 21 April 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28559524 --&gt;

== Tech News: 2025-17 ==

&lt;section begin=&quot;technews-2025-W17&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/17|Translations]] are available.

'''Updates for editors'''
* [[f:Special:MyLanguage/Wikifunctions:Main Page|Wikifunctions]] is now integrated with [[w:dag:Solɔɣu|Dagbani Wikipedia]] since April 15. It is the first project that will be able to call [[f:Special:MyLanguage/Wikifunctions:Introduction|functions from Wikifunctions]] and integrate them in articles. A function is something that takes one or more inputs and transforms them into a desired output, such as adding up two numbers, converting miles into metres, calculating how much time has passed since an event, or declining a word into a case. Wikifunctions will allow users to do that through a simple call of [[f:Special:MyLanguage/Wikifunctions:Catalogue|a stable and global function]], rather than via a local template. [https://www.wikifunctions.org/wiki/Special:MyLanguage/Wikifunctions:Status_updates/2025-04-16]
* A new type of lint error has been created: [[Special:LintErrors/empty-heading|{{int:linter-category-empty-heading}}]] ([[mw:Special:MyLanguage/Help:Lint errors/empty-heading|documentation]]). The [[mw:Special:MyLanguage/Help:Extension:Linter|Linter extension]]'s purpose is to identify wikitext patterns that must or can be fixed in pages and provide some guidance about what the problems are with those patterns and how to fix them. [https://phabricator.wikimedia.org/T368722]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:37}} community-submitted {{PLURAL:37|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* Following its publication on HuggingFace, the &quot;Structured Contents&quot; dataset, developed by Wikimedia Enterprise, is [https://enterprise.wikimedia.com/blog/kaggle-dataset/ now also available on Kaggle]. This Beta initiative is focused on making Wikimedia data more machine-readable for high-volume reusers. They are releasing this beta version in a location that open dataset communities already use, in order to seek feedback, to help improve the product for a future wider release. You can read more about the overall [https://enterprise.wikimedia.com/blog/structured-contents-snapshot-api/#open-datasets Structured Contents project], and about the [https://enterprise.wikimedia.com/blog/structured-contents-wikipedia-infobox/ first release that's freely usable].
* There is no new MediaWiki version this week.

'''Meetings and events'''
* The Editing and Machine Learning Teams invite interested volunteers to a video meeting to discuss [[mw:Special:MyLanguage/Edit check/Peacock check|Peacock check]], which is the latest [[mw:Special:MyLanguage/Edit check|Edit check]] that will detect &quot;peacock&quot; or &quot;overly-promotional&quot; or &quot;non-neutral&quot; language whilst an editor is typing. Editors who work with newcomers, or help to fix this kind of writing, or are interested in how we use artificial intelligence in our projects are encouraged to attend. The [[mw:Special:MyLanguage/Editing team/Community Conversations#Next Conversation|meeting will be on April 28, 2025]] at [https://zonestamp.toolforge.org/1745863200 18:00–19:00 UTC] and hosted on Zoom.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/17|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W17&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:01, 21 April 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28578245 --&gt;

== Wikipedia translation of the week: 2025-18 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Heritage preservation in South Korea]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Korean.Dance-03.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The heritage preservation system of South Korea is a multi-level program aiming to preserve and cultivate Korean cultural heritage. The program is administered by the Cultural Heritage Administration (CHA), and the legal framework is provided by the Cultural Heritage Protection Act of 1962, last updated in 2012. The program started in 1962 and has gradually been extended and upgraded since then. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 00:57, 28 April 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28583422 --&gt;

== Tech News: 2025-18 ==

&lt;section begin=&quot;technews-2025-W18&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/18|Translations]] are available.

'''Updates for editors'''
* Event organizers who host collaborative activities on [[m:Special:MyLanguage/CampaignEvents/Deployment status#Global Deployment Plan|multiple wikis]], including Bengali, Japanese, and Korean Wikipedias, will have access to the [[mw:Special:MyLanguage/Extension:CampaignEvents|CampaignEvents extension]] this week. Also, admins in the Wikipedia where the extension is enabled will automatically be granted the event organizer right soon. They won't have to manually grant themselves the right before they can manage events as [[phab:T386861|requested by a community]].
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:19}} community-submitted {{PLURAL:19|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* The release of the next major version of [[mw:Special:MyLanguage/Codex|Codex]], the design system for Wikimedia, is scheduled for 29 April 2025. Technical editors will have access to the release by the week of 5 May 2025. This update will include a number of [[mw:Special:MyLanguage/Codex/Release_Timeline/2.0#Breaking_changes|breaking changes]] and minor [[mw:Special:MyLanguage/Codex/Release_Timeline/2.0#Visual_changes|visual changes]]. Instructions on handling the breaking and visual changes are documented on [[mw:Special:MyLanguage/Codex/Release Timeline/2.0#|this page]]. Pre-release testing is reported in [[phab:T386298|T386298]], with post-release issues tracked in [[phab:T392379|T392379]] and [[phab:T392390|T392390]].
* Users of [[wikitech:Special:MyLanguage/Help:Wiki_Replicas|Wiki Replicas]] will notice that the database views of &lt;code dir=&quot;ltr&quot;&gt;ipblocks&lt;/code&gt;, &lt;code dir=&quot;ltr&quot;&gt;ipblocks_ipindex&lt;/code&gt;, and &lt;code dir=&quot;ltr&quot;&gt;ipblocks_compat&lt;/code&gt; are [[phab:T390767|now deprecated]]. Users can query the &lt;code dir=&quot;ltr&quot;&gt;[[mw:Special:MyLanguage/Manual:Block_table|block]]&lt;/code&gt; and &lt;code dir=&quot;ltr&quot;&gt;[[mw:Special:MyLanguage/Manual:Block_target_table|block_target]]&lt;/code&gt; new views that mirror the new tables in the production database instead. The deprecated views will be removed entirely from Wiki Replicas in June, 2025.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.44/wmf.27|MediaWiki]]

'''In depth'''
* The latest quarterly [[mw:Special:MyLanguage/Wikimedia Language and Product Localization/Newsletter/2025/April|Language and Internationalization Newsletter]] is now available. This edition includes an overview of the improved [https://test.wikipedia.org/w/index.php?title=Special:ContentTranslation&amp;campaign=contributionsmenu&amp;to=es&amp;filter-type=automatic&amp;filter-id=previous-edits&amp;active-list=suggestions&amp;from=en#/ Content Translation Dashboard Tool], [[mw:Special:MyLanguage/Wikimedia Language and Product Localization/Newsletter/2025/April#Language Support for New and Existing Languages|support for new languages]], [[mw:Special:MyLanguage/Wikimedia Language and Product Localization/Newsletter/2025/April#Wiki Loves Ramadan Articles Made In Content Translation Mobile Workflow|highlights from the Wiki Loves Ramadan campaign]], [[m:Special:MyLanguage/Research:Languages Onboarding Experiment 2024 - Executive Summary|results from the Language Onboarding Experiment]], an analysis of topic diversity in articles, and information on upcoming community meetings and events.

'''Meetings and events'''
* The [[Special:MyLanguage/Grants:Knowledge_Sharing/Connect/Calendar|Let's Connect Learning Clinic]] will take place on [https://zonestamp.toolforge.org/1745937000 April 29 at 14:30 UTC]. This edition will focus on &quot;Understanding and Navigating Conflict in Wikimedia Projects&quot;. You can [[m:Special:MyLanguage/Event:Learning Clinic %E2%80%93 Understanding and Navigating Conflict in Wikimedia Projects (Part_1)|register now]] to attend.
* The [[mw:Special:MyLanguage/Wikimedia Hackathon 2025|2025 Wikimedia Hackathon]], which brings the global technical community together to connect, brainstorm, and hack existing projects, will take place from May 2 to 4th, 2025, at Istanbul, Turkey.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/18|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W18&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:32, 28 April 2025 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28585685 --&gt;

== Wikipedia translation of the week: 2025-19 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Lhamana]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:We-Wa, a Zuni berdache, weaving - NARA - 523796 (cropped).jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Lhamana''', in traditional Zuni culture, are biologically male people who take on the social and ceremonial roles usually performed by women in their culture, at least some of the time. They wear a mixture of women's and men's clothing and much of their work is in the areas usually occupied by Zuni women. Some contemporary lhamana participate in the pan-Indian two-spirit community. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 07:28, 5 May 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28583422 --&gt;

== Tech News: 2025-19 ==

&lt;section begin=&quot;technews-2025-W19&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/19|Translations]] are available.

'''Weekly highlight'''
* The Wikimedia Foundation has shared the latest draft update to their [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026|annual plan]] for next year (July 2025–June 2026). This includes an [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026|executive summary]] (also on [[diffblog:2025/04/25/sharing-the-wikimedia-foundations-2025-2026-draft-annual-plan/|Diff]]), details about the three main [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Goals|goals]] ([[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Product &amp; Technology OKRs|Infrastructure]], [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Goals/Volunteer Support|Volunteer Support]], and [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Goals/Effectiveness|Effectiveness]]), [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Global Trends|global trends]], and the [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Budget Overview|budget]] and [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Financial Model|financial model]]. Feedback and questions are welcome on the [[m:Talk:Wikimedia Foundation Annual Plan/2025-2026|talk page]] until the end of May.

'''Updates for editors'''
* For wikis that have the [[m:Special:MyLanguage/CampaignEvents/Deployment status|CampaignEvents extension enabled]], two new feature improvements have been released:
** Admins can now choose which namespaces are permitted for [[m:Special:MyLanguage/Event Center/Registration|Event Registration]] via [[mw:Special:MyLanguage/Community Configuration|Community Configuration]] ([[mw:Special:MyLanguage/Help:Extension:CampaignEvents/Registration/Permitted namespaces|documentation]]). The default setup is for event registration to be permitted in the Event namespace, but other namespaces (such as the project namespace or WikiProject namespace) can now be added. With this change, communities like WikiProjects can now more easily use Event Registration for their collaborative activities.
** Editors can now [[mw:Special:MyLanguage/Transclusion|transclude]] the Collaboration List on a wiki page ([[mw:Special:MyLanguage/Help:Extension:CampaignEvents/Collaboration list/Transclusion|documentation]]). The Collaboration List is an automated list of events and WikiProjects on the wikis, accessed via {{#special:AllEvents}} ([[w:en:Special:AllEvents|example]]). Now, the Collaboration List can be added to all sorts of wiki pages, such as: a wiki mainpage, a WikiProject page, an affiliate page, an event page, or even a user page.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* Developers who use the &lt;code dir=ltr&gt;moment&lt;/code&gt; library in gadgets and user scripts should revise their code to use alternatives like the &lt;code dir=ltr&gt;Intl&lt;/code&gt; library or the new &lt;code dir=ltr&gt;mediawiki.DateFormatter&lt;/code&gt; library. The &lt;code dir=ltr&gt;moment&lt;/code&gt; library has been deprecated and will begin to log messages in the developer console. You can see a global search for current uses, and [[phab:T392532|ask related questions in this Phabricator task]].
* Developers who maintain a tool that queries the Wikidata term store tables (&lt;code dir=ltr style=&quot;white-space: nowrap;&quot;&gt;wbt_*&lt;/code&gt;) need to update their code to connect to a separate database cluster. These tables are being split into a separate database cluster. Tools that query those tables via the wiki replicas must be adapted to connect to the new cluster instead. [[wikitech:News/2025 Wikidata term store database split|Documentation and related links are available]]. [https://phabricator.wikimedia.org/T390954]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.44/wmf.28|MediaWiki]]

'''In depth'''
* The latest [[mw:Special:MyLanguage/Extension:Chart/Project/Updates|Chart Project newsletter]] is available. It includes updates on preparing to expand the deployment to additional wikis as soon as this week (starting May 6) and scaling up over the following weeks, plus exploring filtering and transforming source data.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/19|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W19&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:15, 6 May 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28665011 --&gt;

== Wikipedia translation of the week: 2025-20 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Gruppo del Sileno]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Parco3.JPG|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Sileno ed Egle con Mnasilo e Cromi''', meglio noto come Gruppo del Sileno, è un monumento in marmo di Carrara, realizzato da Jean-Baptiste Boudard nel 1765 per il Giardino Ducale di Parma; sostituito nel 1991 con una copia in polvere di marmo e resina, l'originale si trova provvisoriamente nel chiostro della Fontana del monastero di San Paolo, in attesa della definitiva collocazione prevista all'interno del palazzetto Eucherio Sanvitale nel parco Ducale. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:28, 12 May 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28709947 --&gt;

== Tech News: 2025-20 ==

&lt;section begin=&quot;technews-2025-W20&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/20|Translations]] are available.

'''Weekly highlight'''
* The [[m:Special:MyLanguage/Wikimedia URL Shortener|&quot;Get shortened URL&quot;]] link on the sidebar now includes a [[phab:T393309|QR code]]. Wikimedia site users can now use it by scanning or downloading it to quickly share and access shared content from Wikimedia sites, conveniently.

'''Updates for editors'''
* The Wikimedia Foundation is working on a system called [[m:Edge Uniques|Edge Uniques]], which will enable [[w:en:A/B testing|A/B testing]], help protect against [[w:en:Denial-of-service attack|distributed denial-of-service attacks]] (DDoS attacks), and make it easier to understand how many visitors the Wikimedia sites have. This is to help more efficiently build tools which help readers, and make it easier for readers to find what they are looking for. Tech News has [[m:Special:MyLanguage/Tech/News/2025/16|previously written about this]]. The deployment will be gradual. Some might see the Edge Uniques cookie the week of 19 May. You can discuss this on the [[m:Talk:Edge Uniques|talk page]].
* Starting May 19, 2025, Event organisers in wikis with the [[mw:Special:MyLanguage/Help:Extension:CampaignEvents|CampaignEvents extension]] enabled can use [[m:Special:MyLanguage/Event Center/Registration|Event Registration]] in the project namespace (e.g., Wikipedia namespace, Wikidata namespace). With this change, communities don't need admins to use the feature. However, wikis that don't want this change can remove and add the permitted namespaces at [[Special:CommunityConfiguration/CampaignEvents]].
* The Wikipedia project now has a {{int:project-localized-name-group-wikipedia/en}} in [[d:Q36720|Nupe]] ([[w:nup:|&lt;code&gt;w:nup:&lt;/code&gt;]]). This is a language primarily spoken in the North Central region of Nigeria. Speakers of this language are invited to contribute to [[w:nup:Tatacin feregi|new Wikipedia]].
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* Developers can now access pre-parsed Dutch Wikipedia, amongst others (English, German, French, Spanish, Italian, and Portuguese) through the [https://enterprise.wikimedia.com/docs/snapshot/#structured-contents-snapshot-bundle-info-beta Structured Contents snapshots (beta)]. The content includes parsed Wikipedia abstracts, descriptions, main images, infoboxes, article sections, and references.
* The &lt;code dir=&quot;ltr&quot;&gt;/page/data-parsoid&lt;/code&gt; REST API endpoint is no longer in use and will be deprecated. It is [[phab:T393557|scheduled to be turned off]] on June 7, 2025.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.1|MediaWiki]]

'''In depth'''
* The [https://wikitech.wikimedia.org/wiki/News/2025_Cloud_VPS_VXLAN_IPv6_migration IPv6 support] is a newly introduced Cloud virtual network that significantly boosts Wikimedia platforms' scalability, security, and readiness for the future. If you are a technical contributor eager to learn more, check out [https://techblog.wikimedia.org/2025/05/06/wikimedia-cloud-vps-ipv6-support/ this blog post] for an in-depth look at the journey to IPv6.

'''Meetings and events'''
* The 2nd edition of 2025 of [[m:Special:MyLanguage/Afrika Baraza|Afrika Baraza]], a virtual platform for African Wikimedians to connect, will take place on [https://zonestamp.toolforge.org/1747328400 May 15 at 17:00 UTC]. This edition will focus on discussions regarding [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026|Wikimedia Annual planning and progress]].
* The [[m:Special:MyLanguage/MENA Connect Community Call|MENA Connect Community Call]], a virtual meeting for [[w:en:Middle East and North Africa|MENA]] Wikimedians to connect, will take place on [https://zonestamp.toolforge.org/1747501200 May 17 at 17:00 UTC]. You can [[m:Event:MENA Connect (Wiki_Diwan) APP Call|register now]] to attend.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/20|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W20&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:38, 12 May 2025 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28714188 --&gt;

== Wikipedia translation of the week: 2025-21 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Lorrin A. Thurston]]'''&lt;br /&gt; &lt;small&gt;''([[:fi:Lorrin Thurston]])&amp;#32;([[:ko:로린 A. 서스턴]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Lorrinandrewsthurston1892.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Lorrin Andrews Thurston''' (July 31, 1858 – May 11, 1931) was a Hawaiian citizen lawyer, politician, and businessman. Thurston played a prominent role in the revolution that overthrew the Hawaiian Kingdom to replace Queen Liliʻuokalani with the Republic of Hawaii, with discreet US support for which Congress much later apologized. He published the Pacific Commercial Advertiser (a forerunner of the present-day Honolulu Star-Advertiser), and owned other enterprises. From 1906 to 1916, he and his network lobbied with national politicians to create a national park to preserve the Hawaiian volcanoes. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:33, 19 May 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28731710 --&gt;

== Tech News: 2025-21 ==

&lt;section begin=&quot;technews-2025-W21&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/21|Translations]] are available.

'''Weekly highlight'''
* The Editing Team and the Machine Learning Team are working on a new check for newcomers: [[mw:Edit check/Peacock check|Peacock check]]. Using a prediction model, this check will encourage editors to improve the tone of their edits, using artificial intelligence. We invite volunteers to review the first version of the Peacock language model for the following languages: Arabic, Spanish, Portuguese, English, and Japanese. Users from these wikis interested in reviewing this model are [[mw:Edit check/Peacock check/model test|invited to sign up at MediaWiki.org]]. The deadline to sign up is on May 23, which will be the start date of the test.

'''Updates for editors'''

* From May 20, 2025, [[m:Special:MyLanguage/Oversight policy|oversighters]] and [[m:Special:MyLanguage/Meta:CheckUsers|checkusers]] will need to have their accounts secured with two-factor authentication (2FA) to be able to use their advanced rights. All users who belong to these two groups and do not have 2FA enabled have been informed. In the future, this requirement may be extended to other users with advanced rights. [[m:Special:MyLanguage/Mandatory two-factor authentication for users with some extended rights|Learn more]].
* [[File:Octicons-gift.svg|12px|link=|class=skin-invert|Wishlist item]]  [[m:Special:MyLanguage/Community Wishlist Survey 2023/Multiblocks|Multiblocks]] will begin mass deployment by the end of the month: all non-Wikipedia projects plus Catalan Wikipedia will adopt Multiblocks in the week of May 26, while all other Wikipedias will adopt it in the week of June 2. Please [[m:Talk:Community Wishlist Survey 2023/Multiblocks|contact the team]] if you have concerns. Administrators can test the new user interface now on your own wiki by browsing to [{{fullurl:Special:Block|usecodex=1}} {{#special:Block}}?usecodex=1], and can test the full multiblocks functionality [[testwiki:Special:Block|on testwiki]]. Multiblocks is the feature that makes it possible for administrators to impose different types of blocks on the same user at the same time. See the [[mw:Special:MyLanguage/Help:Manage blocks|help page]] for more information. [https://phabricator.wikimedia.org/T377121]
* Later this week, the [[{{#special:SpecialPages}}]] listing of almost all special pages will be updated with a new design. This page has been [[phab:T219543|redesigned]] to improve the user experience in a few ways, including: The ability to search for names and aliases of the special pages, sorting, more visible marking of restricted special pages, and a more mobile-friendly look. The new version can be [https://meta.wikimedia.beta.wmflabs.org/wiki/Special:SpecialPages previewed] at Beta Cluster now, and feedback shared in the task. [https://phabricator.wikimedia.org/T219543]
* The [[mw:Special:MyLanguage/Extension:Chart|Chart extension]] is being enabled on more wikis. For a detailed list of when the extension will be enabled on your wiki, please read the [[mw:Special:MyLanguage/Extension:Chart/Project#Deployment Timeline|deployment timeline]].
* [[f:Special:MyLanguage/Wikifunctions:Main Page|Wikifunctions]] will be deployed on May 27 on five Wiktionaries: [[wikt:ha:|Hausa]], [[wikt:ig:|Igbo]], [[wikt:bn:|Bengali]], [[wikt:ml:|Malayalam]], and [[wikt:dv:|Dhivehi/Maldivian]]. This is the second batch of deployment planned for the project. After deployment, the projects will be able to call [[f:Special:MyLanguage/Wikifunctions:Introduction|functions from Wikifunctions]] and integrate them in their pages. A function is something that takes one or more inputs and transforms them into a desired output, such as adding up two numbers, converting miles into metres, calculating how much time has passed since an event, or declining a word into a case. Wikifunctions will allow users to do that through a simple call of [[f:Special:MyLanguage/Wikifunctions:Catalogue|a stable and global function]], rather than via a local template.
* Later this week, the Wikimedia Foundation will publish a hub for [[diffblog:2024/07/09/on-the-value-of-experimentation/|experiments]]. This is to showcase and get user feedback on product experiments. The experiments help the Wikimedia movement [[diffblog:2023/07/13/exploring-paths-for-the-future-of-free-knowledge-new-wikipedia-chatgpt-plugin-leveraging-rich-media-social-apps-and-other-experiments/|understand new users]], how they interact with the internet and how it could affect the Wikimedia movement. Some examples are [[m:Special:MyLanguage/Future Audiences/Generated Video|generated video]], the [[m:Special:MyLanguage/Future Audiences/Roblox game|Wikipedia Roblox speedrun game]] and [[m:Special:MyLanguage/Future Audiences/Discord bot|the Discord bot]].
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:29}} community-submitted {{PLURAL:29|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, there was a bug with creating an account using the API, which has now been fixed. [https://phabricator.wikimedia.org/T390751]

'''Updates for technical contributors'''
* Gadgets and user scripts that interact with [[{{#special:Block}}]] may need to be updated to work with the new [[mw:Special:MyLanguage/Help:Manage blocks|manage blocks interface]]. Please review the [[mw:Help:Manage blocks/Developers|developer guide]] for more information. If you need help or are unable to adapt your script to the new interface, please let the team know on the [[mw:Help talk:Manage blocks/Developers|talk page]]. [https://phabricator.wikimedia.org/T377121]
* The &lt;code dir=ltr&gt;mw.title&lt;/code&gt; object allows you to get information about a specific wiki page in the [[w:en:Wikipedia:Lua|Lua]] programming language. Starting this week, a new property will be added to the object, named &lt;code dir=ltr&gt;isDisambiguationPage&lt;/code&gt;. This property allows you to check if a page is a disambiguation page, without the need to write a custom function. [https://phabricator.wikimedia.org/T71441]
* [[File:Octicons-tools.svg|15px|link=|class=skin-invert|Advanced item]] User script developers can use a [[toolforge:gitlab-content|new reverse proxy tool]] to load javascript and css from [[gitlab:|gitlab.wikimedia.org]] with &lt;code dir=ltr&gt;mw.loader.load&lt;/code&gt;. The tool's author hopes this will enable collaborative development workflows for user scripts including linting, unit tests, code generation, and code review on &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;gitlab.wikimedia.org&lt;/bdi&gt; without a separate copy-and-paste step to publish scripts to a Wikimedia wiki for integration and acceptance testing. See [[wikitech:Tool:Gitlab-content|Tool:Gitlab-content on Wikitech]] for more information.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.2|MediaWiki]]

'''Meetings and events'''
* The 12th edition of [[m:Special:MyLanguage/Wiki Workshop 2025|Wiki Workshop 2025]], a forum that brings together researchers that explore all aspects of Wikimedia projects, will be held virtually on 21-22 May. Researchers can [https://pretix.eu/wikimedia/wikiworkshop2025/ register now].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/21|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W21&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:13, 19 May 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28724712 --&gt;

== Wikipedia translation of the week: 2025-22 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Lamiera bugnata]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Tread plate]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Diamond Plate.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
Una '''lamiera bugnata''' o mandorlata è una lamiera di metallo ottenuta dalla laminazione di una bramma attraverso rulli che, tramite punzonatura o goffratura, imprimono sulla lamina rilievi a forma di rombo o ellisse, detti bugne. Nel caso questi rilievi siano alternati singolarmente nei due assi, si parla di lamiera diamantata, mentre se le forme sono predisposte in maniera parallela per formare piccoli quadranti tra di loro tangenti, questo pattern viene identificato con il nome di mandorlato.

We tend to ignore the fact that this type of plate is the only reason we don't slip when we walk on steel and wet or frozen surfaces. The Italian article it's short but quite complete, and has just the right amount of citations, unlike other poor languages' versions. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 06:03, 26 May 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28751788 --&gt;

== Tech News: 2025-22 ==

&lt;section begin=&quot;technews-2025-W22&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/22|Translations]] are available.

'''Weekly highlight'''
* A community-wide discussion about a very delicate issue for the development of [[m:Special:MyLanguage/Abstract Wikipedia|Abstract Wikipedia]] is now open on Meta: where to store the abstract content that will be developed through functions from Wikifunctions and data from Wikidata. The discussion is open until June 12 at [[m:Special:MyLanguage/Abstract Wikipedia/Location of Abstract Content|Abstract Wikipedia/Location of Abstract Content]], and every opinion is welcomed. The decision will be made and communicated after the consultation period by the Foundation.

'''Updates for editors'''
* Since last week, on all wikis except [[phab:T388604|the largest 20]], people using the mobile visual editor will have [[phab:T385851|additional tools in the menu bar]], accessed using the new &lt;code&gt;+&lt;/code&gt; toolbar button. To start, the new menu will include options to add: citations, hieroglyphs, and code blocks. Deployment to the remaining wikis is [[phab:T388605|scheduled]] to happen in June.
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] The &lt;code dir=ltr&gt;[[mw:Special:MyLanguage/Help:Extension:ParserFunctions##ifexist|#ifexist]]&lt;/code&gt; parser function will no longer register a link to its target page. This will improve the usefulness of [[{{#special:WantedPages}}]], which will eventually only list pages that are the target of an actual red link. This change will happen gradually as the source pages are updated. [https://phabricator.wikimedia.org/T14019]
* This week, the Moderator Tools team will launch [[mw:Special:MyLanguage/2025 RecentChanges Language Agnostic Revert Risk Filtering|a new filter to Recent Changes]], starting at Indonesian Wikipedia. This new filter highlights edits that are likely to be reverted. The goal is to help Recent Changes patrollers identify potentially problematic edits. Other wikis will benefit from this filter in the future.
* Upon clicking an empty search bar, logged-out users will see suggestions of articles for further reading. The feature will be available on both desktop and mobile. Readers of Catalan, Hebrew, and Italian Wikipedias and some sister projects will receive the change between May 21 and mid-June. Readers of other wikis will receive the change later. The goal is to encourage users to read the wikis more. [[mw:Special:MyLanguage/Reading/Web/Content Discovery Experiments/Search Suggestions|Learn more]].
* Some users of the Wikipedia Android app can use a new feature for readers, [[mw:Special:MyLanguage/Wikimedia Apps/Team/Android/TrivaGame|WikiGames]], a daily trivia game based on real historical events. The release has started as an A/B test, available to 50% of users in the following languages: English, French, Portuguese, Russian, Spanish, Arabic, Chinese, and Turkish.
* The [[mw:Special:MyLanguage/Extension:Newsletter|Newsletter extension]] that is available on MediaWiki.org allows the creation of [[mw:Special:Newsletters|various newsletters]] for global users. The extension can now publish new issues as section links on an existing page, instead of requiring a new page for each issue. [https://phabricator.wikimedia.org/T393844]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:32}} community-submitted {{PLURAL:32|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* The previously deprecated &lt;code dir=ltr&gt;[[mw:Special:MyLanguage/Manual:Ipblocks table|ipblocks]]&lt;/code&gt; views in [[wikitech:Help:Wiki Replicas|Wiki Replicas]] will be removed in the beginning of June. Users are encouraged to query the new &lt;code dir=ltr&gt;[[mw:Special:MyLanguage/Manual:Block table|block]]&lt;/code&gt; and &lt;code dir=ltr&gt;[[mw:Special:MyLanguage/Manual:Block target table|block_target]]&lt;/code&gt; views instead.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.3|MediaWiki]]

'''Meetings and events'''
* [[d:Special:MyLanguage/Event:Wikidata and Sister Projects|Wikidata and Sister Projects]] is a multi-day online event that will focus on how Wikidata is integrated to Wikipedia and the other Wikimedia projects. The event runs from May 29 – June 1. You can [[d:Special:MyLanguage/Event:Wikidata and Sister Projects#Sessions|read the Program schedule]] and [[d:Special:RegisterForEvent/1291|register]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/22|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W22&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:05, 26 May 2025 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28788673 --&gt;

== Wikipedia translation of the week: 2025-23 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Angelo azzurro (cocktail)]]'''&lt;br /&gt; &lt;small&gt;''([[:es:Ángel azul (cóctel)]])&amp;#32;([[:fr:Ange bleu (cocktail)]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Angelo Azzurro Cocktail.png|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
L''''angelo azzurro''' è un cocktail alcolico italiano. È considerato uno dei cocktail più popolari in Italia negli anni novanta, insieme al B-52 e all'Invisibile. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 05:39, 2 June 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28788623 --&gt;

== Tech News: 2025-23 ==

&lt;section begin=&quot;technews-2025-W23&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/23|Translations]] are available.

'''Weekly highlight'''
* The [[mw:Special:MyLanguage/Extension:Chart|Chart extension]] is now available on all Wikimedia wikis. Editors can use this new extension to create interactive data visualizations like bar, line, area, and pie charts. Charts are designed to replace many of the uses of the legacy [[mw:Special:MyLanguage/Extension:Graph|Graph extension]].

'''Updates for editors'''
* It is now easier to configure automatic citations for your wiki within the visual editor's [[mw:Special:MyLanguage/Citoid/Enabling Citoid on your wiki|citation generator]]. Administrators can now set a default template by using the &lt;code dir=ltr&gt;_default&lt;/code&gt; key in the local &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[MediaWiki:Citoid-template-type-map.json]]&lt;/bdi&gt; page ([[mw:Special:Diff/6969653/7646386|example diff]]). Setting this default will also help to future-proof your existing configurations when [[phab:T347823|new item types]] are added in the future. You can still set templates for individual item types as they will be preferred to the default template. [https://phabricator.wikimedia.org/T384709]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:20}} community-submitted {{PLURAL:20|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* Starting the week of June 2, bots logging in using &lt;code dir=ltr&gt;action=login&lt;/code&gt; or &lt;code dir=ltr&gt;action=clientlogin&lt;/code&gt; will fail more often. This is because of stronger protections against suspicious logins. Bots using [[mw:Special:MyLanguage/Manual:Bot passwords|bot passwords]] or using a loginless authentication method such as [[mw:Special:MyLanguage/OAuth/Owner-only consumers|OAuth]] are not affected. If your bot is not using one of those, you should update it; using &lt;code dir=ltr&gt;action=login&lt;/code&gt; without a bot password was deprecated [[listarchive:list/wikitech-l@lists.wikimedia.org/message/3EEMN7VQX5G7WMQI5K2GP5JC2336DPTD/|in 2016]]. For most bots, this only requires changing what password the bot uses. [https://phabricator.wikimedia.org/T395205]
* From this week, Wikimedia wikis will allow ES2017 features in JavaScript code for official code, gadgets, and user scripts. The most visible feature of ES2017 is &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;async&lt;/code&gt;/&lt;code&gt;await&lt;/code&gt;&lt;/bdi&gt; syntax, allowing for easier-to-read code. Until this week, the platform only allowed up to ES2016, and a few months before that, up to ES2015. [https://phabricator.wikimedia.org/T381537]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.4|MediaWiki]]

'''Meetings and events'''
* Scholarship applications to participate in the [[m:Special:MyLanguage/GLAM Wiki 2025|GLAM Wiki Conference 2025]] are now open. The conference will take place from 30 October to 1 November, in Lisbon, Portugal. GLAM contributors who lack the means to support their participation can [[m:Special:MyLanguage/GLAM Wiki 2025/Scholarships|apply here]]. Scholarship applications close on June 7th.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/23|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W23&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:55, 2 June 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28819186 --&gt;

== Wikipedia translation of the week: 2025-24 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:fi:Kotiryssä]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Kotiryssä]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
A '''kotiryssä''' (jocular Finnish: one’s home Russky or home Russian) was a Soviet or Russian contact person of a Finnish politician, bureaucrat, businessman or other important person. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:33, 9 June 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28788623 --&gt;

== Tech News: 2025-24 ==

&lt;section begin=&quot;technews-2025-W24&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/24|Translations]] are available.

'''Weekly highlight'''
* The [[mw:Special:MyLanguage/Trust and Safety Product|Trust and Safety Product team]] is finalizing work needed to roll out [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|temporary accounts]] on large Wikipedias later this month. The team has worked with stewards and other users with extended rights to predict and address many use cases that may arise on larger wikis, so that community members can continue to effectively moderate and patrol temporary accounts. This will be the second of three phases of deployment – the last one will take place in September at the earliest. For more information about the recent developments on the project, [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts/Updates|see this update]]. If you have any comments or questions, write on the [[mw:Talk:Trust and Safety Product/Temporary Accounts|talk page]], and [[m:Event:CEE Catch up Nr. 10 (June 2025)|join a CEE Catch Up]] this Tuesday.

'''Updates for editors'''
* [[File:Octicons-gift.svg|12px|link=|class=skin-invert|Wishlist item]] The [[mw:Special:MyLanguage/Help:Watchlist expiry|watchlist expiry]] feature allows editors to watch pages for a limited period of time. After that period, the page is automatically removed from your watchlist. Starting this week, you can set a preference for the default period of time to watch pages. The [[Special:Preferences#mw-prefsection-watchlist-pageswatchlist|preferences]] also allow you to set different default watch periods for editing existing pages, pages you create, and when using rollback. [https://phabricator.wikimedia.org/T265716]
[[File:Talk pages default look (April 2023).jpg|thumb|alt=Screenshot of the visual improvements made on talk pages|Example of a talk page with the new design, in French.]]
* The appearance of talk pages will change at almost all Wikipedias ([[m:Special:MyLanguage/Tech/News/2024/19|some]] have already received this design change, [[phab:T379264|a few]] will get these changes later). You can read details about the changes [[diffblog:2024/05/02/making-talk-pages-better-for-everyone/|on ''Diff'']]. It is possible to opt out of these changes [[Special:Preferences#mw-prefsection-editing-discussion|in user preferences]] (&quot;{{int:discussiontools-preference-visualenhancements}}&quot;). [https://phabricator.wikimedia.org/T319146][https://phabricator.wikimedia.org/T392121]
* Users with specific extended rights (including administrators, bureaucrats, checkusers, oversighters, and stewards) can now have IP addresses of all temporary accounts [[phab:T358853|revealed automatically]] during time-limited periods where they need to combat high-speed account-hopping vandalism. This feature was requested by stewards. [https://phabricator.wikimedia.org/T386492]
* This week, the Moderator Tools and Machine Learning teams will continue the rollout of [[mw:Special:MyLanguage/2025 RecentChanges Language Agnostic Revert Risk Filtering|a new filter to Recent Changes]], releasing it to several more Wikipedias. This filter utilizes the Revert Risk model, which was created by the Research team, to highlight edits that are likely to be reverted and help Recent Changes patrollers identify potentially problematic contributions. The feature will be rolled out to the following Wikipedias: {{int:project-localized-name-afwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-bewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-bnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-cywiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hawwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-iswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kkwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-simplewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-trwiki/en}}. The rollout will continue in the coming weeks to include [[mw:Special:MyLanguage/2025 RecentChanges Language Agnostic Revert Risk Filtering|the rest of the Wikipedias in this project]]. [https://phabricator.wikimedia.org/T391964]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* AbuseFilter editors active on Meta-Wiki and large Wikipedias are kindly asked to update AbuseFilter to make it compatible with temporary accounts. A link to the instructions and the private lists of filters needing verification are [[phab:T369611|available on Phabricator]].
* Lua modules now have access to the name of a page's associated thumbnail image, and on [https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/2e4ab14aa15bb95568f9c07dd777065901eb2126/wmf-config/InitialiseSettings.php#10849 some wikis] to the WikiProject assessment information. This is possible using two new properties on [[mw:Special:MyLanguage/Extension:Scribunto/Lua reference manual#added-by-extensions|mw.title objects]], named &lt;code dir=ltr&gt;pageImage&lt;/code&gt; and &lt;code dir=ltr&gt;pageAssessments&lt;/code&gt;. [https://phabricator.wikimedia.org/T131911][https://phabricator.wikimedia.org/T380122]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.5|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/24|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W24&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:17, 10 June 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28846858 --&gt;

== Wikipedia translation of the week: 2025-25 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Future self]]'''&lt;br /&gt; &lt;small&gt;''([[:pl:Przyszła jaźń]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
In the psychology of self, the '''future self''' concerns the processes and consequences associated with thinking about oneself in the future. People think about their future selves similarly to how they think about other people. The extent to which people feel psychologically connected (e.g., similarity, closeness) to their future self influences how well they treat their future self. When people feel connected to their future self, they are more likely to save for retirement, make healthy decisions, and avoid ethical transgressions. Interventions that increase feelings of connectedness with future selves can improve future-oriented decision making across these domains. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:18, 16 June 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28788623 --&gt;

== Tech News: 2025-25 ==

&lt;section begin=&quot;technews-2025-W25&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/25|Translations]] are available.

'''Updates for editors'''
* You can [https://wikimediafoundation.limesurvey.net/359761?lang=en nominate your favorite tools] for the sixth edition of the [[m:Special:MyLanguage/Coolest Tool Award|Coolest Tool Award]]. Nominations are anonymous and will be open until June 25. You can re-use the survey to nominate multiple tools.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:33}} community-submitted {{PLURAL:33|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.6|MediaWiki]]

'''In depth'''
* Foundation staff and technical volunteers use Wikimedia APIs to build the tools, applications, features, and integrations that enhance user experiences. Over the coming years, the MediaWiki Interfaces team will be investing in Wikimedia web (HTTP) APIs to better serve technical volunteer needs and protect Wikimedia infrastructure from potential abuse. You can [https://techblog.wikimedia.org/2025/06/12/apis-as-a-product-investing-in-the-current-and-next-generation-of-technical-contributors/ read more about their plans to evolve the APIs in this Techblog post].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/25|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W25&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:39, 16 June 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28870688 --&gt;

== Wikipedia translation of the week: 2025-26 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Pictorial map]]'''&lt;br /&gt; &lt;small&gt;''([[:fa:نقشه تصویری]])&amp;#32;([[:ja:絵地図]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Blake Britain Spearhead of Attack.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Pictorial maps''' (also known as illustrated maps, panoramic maps, perspective maps, bird's-eye view maps, and geopictorial maps) depict a given territory with a more artistic rather than technical style. It is a type of map in contrast to road map, atlas, or topographic map. The cartography can be a sophisticated 3-D perspective landscape or a simple map graphic enlivened with illustrations of buildings, people and animals. They can feature all sorts of varied topics like historical events, legendary figures or local agricultural products and cover anything from an entire continent to a college campus. Drawn by specialized artists and illustrators, pictorial maps are a rich, centuries-old tradition and a diverse art form that ranges from cartoon maps on restaurant placemats to treasured art prints in museums. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:18, 23 June 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28788623 --&gt;

== Tech News: 2025-26 ==

&lt;section begin=&quot;technews-2025-W26&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/26|Translations]] are available.

'''Weekly highlight'''
* This week, the Moderator Tools and Machine Learning teams will continue the rollout of [[mw:Special:MyLanguage/2025 RecentChanges Language Agnostic Revert Risk Filtering|a new filter to Recent Changes]], releasing it to the third and last batch of Wikipedias. This filter utilizes the Revert Risk model, which was created by the Research team, to highlight edits that are likely to be reverted and help Recent Changes patrollers identify potentially problematic contributions. The feature will be rolled out to the following Wikipedias: {{int:project-localized-name-azwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-lawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mkwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mlwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-mrwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nnwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-pawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-swwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-tlwiki/en}}. The rollout will continue in the coming weeks to include [[mw:Special:MyLanguage/2025 RecentChanges Language Agnostic Revert Risk Filtering|the rest of the Wikipedias in this project]]. [https://phabricator.wikimedia.org/T391964]

'''Updates for editors'''
* Last week, [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|temporary accounts]] were rolled out on Czech, Korean, and Turkish Wikipedias. This and next week, deployments on larger Wikipedias will follow. [[mw:Talk:Trust and Safety Product/Temporary Accounts|Share your thoughts]] about the project. [https://phabricator.wikimedia.org/T340001]
* Later this week, the Editing team will release [[mw:Special:MyLanguage/Help:Edit check#Multi check|Multi Check]] to all Wikipedias (except English Wikipedia). This feature shows multiple [[mw:Special:MyLanguage/Help:Edit check#Reference check|Reference checks]] within the editing experience. This encourages users to add citations when they add multiple new paragraphs to a Wikipedia article. This feature was previously available as an A/B test. [https://analytics.wikimedia.org/published/reports/editing/multi_check_ab_test_report_final.html#summary-of-results The test shows] that users who are shown multiple checks are 1.3 times more likely to add a reference to their edit, and their edit is less likely to be reverted (-34.7%). [https://phabricator.wikimedia.org/T395519]
* A few pages need to be renamed due to software updates and to match more recent Unicode standards. All of these changes are related to title-casing changes. Approximately 71 pages and 3 files will be renamed, across 15 wikis; the complete list is in [[phab:T396903|the task]]. The developers will rename these pages next week, and they will fix redirects and embedded file links a few minutes later via a system settings update.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:24}} community-submitted {{PLURAL:24|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a bug was fixed that had caused pages to scroll upwards when text near the top was selected. [https://phabricator.wikimedia.org/T364023]

'''Updates for technical contributors'''
* Editors can now use Lua modules to filter and transform tabular data for use with [[mw:Special:MyLanguage/Extension:Chart|Extension:Chart]]. This can be used for things like selecting a subset of rows or columns from the source data, converting between units, statistical processing, and many other useful transformations. [[mw:Special:MyLanguage/Extension:Chart/Transforms|Information on how to use transforms is available]]. [https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:Chart/Project/Updates]
* The &lt;code dir=ltr&gt;all_links&lt;/code&gt; variable in [[Special:AbuseFilter|AbuseFilter]] is now renamed to &lt;code dir=ltr&gt;new_links&lt;/code&gt; for consistency with other variables. Old usages will still continue to work. [https://phabricator.wikimedia.org/T391811]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.7|MediaWiki]]

'''In depth'''
* The latest quarterly [[mw:Special:MyLanguage/Growth/Newsletters/34|Growth newsletter]] is available. It includes: the recent updates for the &quot;Add a Link&quot; Task, two new Newcomer Engagement Features, and updates to Community Configuration.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/26|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W26&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:21, 23 June 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28870688 --&gt;

== Wikipedia translation of the week: 2025-27 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Queen Elizabeth University Hospital]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:QEUH.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Queen Elizabeth University Hospital''' (QEUH) is a 1,677-bed acute hospital located in Govan, in the south-west of Glasgow, Scotland. The hospital is built on the site of the former Southern General Hospital and opened at the end of April 2015. The hospital comprises a 1,109-bed adult hospital, a 256-bed children's hospital and two major Emergency Departments; one for adults and one for children. There is also an Immediate Assessment Unit for local GPs and out-of-hours services, to send patients directly, without having to be processed through the Emergency Department. The retained buildings from the former Southern General Hospital include the Maternity Unit, the Institute of Neurological Sciences, the Langlands Unit for medicine of the elderly and the laboratory. The whole facility is operated by NHS Greater Glasgow and Clyde, and is one of the largest acute hospital campuses in Europe. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:05, 30 June 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28788623 --&gt;

== Tech News: 2025-27 ==

&lt;section begin=&quot;technews-2025-W27&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/27|Translations]] are available.

'''Weekly highlight'''
* The [[mw:Special:MyLanguage/Help:Extension:CampaignEvents|CampaignEvents extension]] has been enabled on all Wikipedias. The extension makes it easier to organize and participate in collaborative activities, like edit-a-thons and WikiProjects, on the wikis. The extension has three features: [[m:Special:MyLanguage/Event Center/Registration|Event Registration]], [[m:Special:MyLanguage/CampaignEvents/Collaboration list|Collaboration List]], and [[m:Campaigns/Foundation Product Team/Invitation list|Invitation List]]. To request the extension for your wiki, visit the [[m:Special:MyLanguage/CampaignEvents/Deployment status#How to Request the CampaignEvents Extension for your wiki|Deployment information page]].

'''Updates for editors'''
* AbuseFilter maintainers can now [[mw:Special:MyLanguage/Extension:IPReputation/AbuseFilter variables|match against IP reputation data]] in [[mw:Special:MyLanguage/Extension:AbuseFilter|AbuseFilters]]. IP reputation data is information about the proxies and VPNs associated with the user's IP address. This data is not shown publicly and is not generated for actions performed by registered accounts. [https://phabricator.wikimedia.org/T354599]
* Hidden content that is within [[mw:Special:MyLanguage/Manual:Collapsible elements|collapsible parts of wikipages]] will now be revealed when someone searches the page using the web browser's &quot;Find in page&quot; function (Ctrl+F or ⌘F) in supporting browsers. [https://phabricator.wikimedia.org/T327893][https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/hidden#browser_compatibility]
* [[File:Octicons-gift.svg|12px|link=|class=skin-invert|Wishlist item]] A new feature, called [[mw:Special:MyLanguage/Help:TemplateData/Template discovery|Favourite Templates]], will be deployed later this week on all projects (except English Wikipedia, which will receive the feature next week), following a piloting phase on Polish and Arabic Wikipedia, and Italian and English Wikisource. The feature will provide a better way for new and experienced contributors to recall and discover templates via the template dialog, by allowing users to put templates on a special &quot;favourite list&quot;. The feature works with both the visual editor and the wikitext editor. The feature is a [[m:Special:MyLanguage/Community Wishlist/Focus areas/Template recall and discovery|community wishlist focus area]].
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:31}} community-submitted {{PLURAL:31|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a bug was fixed that had caused some Notifications to be sent multiple times. [https://phabricator.wikimedia.org/T397103]

'''Updates for technical contributors'''
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.8|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/27|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W27&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:41, 30 June 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28917415 --&gt;

== Wikipedia translation of the week: 2025-28 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Non-constituency Member of Parliament]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
A '''Non-constituency Member of Parliament''' (NCMP) is a member of an opposition political party in Singapore who, as stipulated in Article 39 of the Constitution and the Parliamentary Elections Act, is declared to have been elected a Member of Parliament (MP) without constituency representation, despite having lost in a general election, by virtue of having been one of the opposition candidates with the highest vote shares among the unelected. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:10, 7 July 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28788623 --&gt;

== Tech News: 2025-28 ==

&lt;section begin=&quot;technews-2025-W28&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/28|Translations]] are available.

'''Weekly highlight'''
* [[mw:Special:MyLanguage/Help:Temporary accounts|Temporary accounts]] have been rolled out on 18 large and medium-sized Wikipedias, including German, Japanese, French, and Chinese. Now, about 1/3 of all logged-out activity across wikis is coming from temporary accounts. Users involved in patrolling may be interested in two new documentation pages: [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts/Access to IP|Access to IP]], explaining everything related to access to temporary account IP addresses, and [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts/Repository|Repository]] with a list of new gadgets and user scripts.

'''Updates for editors'''
* Anyone can play an experimental new game, [[mw:Special:MyLanguage/New Engagement Experiments/WikiRun|WikiRun]], that lets you race through Wikipedia by clicking from one article to another, aiming to reach a target page in as few steps and in as little time as possible. The project's goal is to explore new ways of engaging readers. [https://wikirun-game.toolforge.org/ Try playing the game] and let the team know what you think [[mw:Talk:New Engagement Experiments/WikiRun|on the talk page]].
* Users of the Wikipedia Android app in some languages can now play the new [[mw:Special:MyLanguage/Wikimedia Apps/Team/Android/TrivaGame|trivia game]]. ''Which came first?'' is a simple history game where you guess which of two events happened earlier on today's date. It was previously available as an A/B test. It is now available to all users in English, German, French, Spanish, Portuguese, Russian, Arabic, Turkish, and Chinese. The goal of the feature is to help engage with new generations of readers. [https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2025/22]
* Users of the iOS Wikipedia App in some languages may see a new tabbed browsing feature that enables you to open multiple tabs while reading. This feature makes it easier to explore related topics and switch between articles. The A/B test is currently running in Arabic, English, and Japanese in selected regions. More details are available on the [[mw:Special:MyLanguage/Wikimedia Apps/Team/iOS/Tabbed Browsing (Tabs)|Tabbed Browsing project page]].
* Bureaucrats on Wikimedia wikis can now use [[{{#special:VerifyOATHForUser}}]] to check if users have enabled [[mw:Special:MyLanguage/Help:Two-factor authentication|two-factor authentication]]. [https://phabricator.wikimedia.org/T265726]
* [[File:Octicons-gift.svg|12px|link=|class=skin-invert|Wishlist item]] A new feature related to [[m:Special:MyLanguage/Community Wishlist/Focus areas/Template recall and discovery|Template Recall and Discovery]] will be deployed later this week to all Wikimedia projects: a [[mw:Special:MyLanguage/Help:TemplateData/Template discovery#Template categories|template category browser]] will be introduced to assist users in finding templates to put in their “favourite” list. The browser will allow users to browse a list of templates which have been organised into a given category tree. The feature has been requested by the community [[m:Special:MyLanguage/Community Wishlist/Wishes/Select templates by categories|through the Community Wishlist]].
* It is now possible to access watchlist preferences from the watchlist page. Also the redundant button to edit the watchlist has been removed. [https://www.mediawiki.org/wiki/Moderator_Tools/Watchlist]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* As part of [[mw:MediaWiki_1.44|MediaWiki 1.44]] there is now a unified built-in Notifications system that makes it easier for developers to send, manage, and customize notifications. Check out the updated documentation at [[mw:Manual:Notifications|Manual:Notifications]], information about migration in [[phab:T388663|T388663]] and details on deprecated hooks in [[phab:T389624|T389624]].
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.9|MediaWiki]]

'''Meetings and events'''
* [[d:Special:MyLanguage/Event:WikidataCon 2025|WikidataCon 2025]], the conference dedicated to Wikidata is now open for [https://pretalx.com/wikidatacon-2025/cfp session proposals] and for [[d:Special:RegisterForEvent/1340|registration]]. This year's event will be held online from October 31 – November 02 and will explore on the theme of &quot;Connecting People through Linked Open Data&quot;.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/28|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W28&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:06, 8 July 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28930584 --&gt;

== Wikipedia translation of the week: 2025-29 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Immunolabeling]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Immunolabeling process image.png|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Immunolabeling''' is a biochemical process that enables the detection and localization of an antigen to a particular site within a cell, tissue, or organ. Antigens are organic molecules, usually proteins, capable of binding to an antibody. These antigens can be visualized using a combination of antigen-specific antibody as well as a means of detection, called a tag, that is covalently linked to the antibody 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
---[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 13:44, 14 July 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28945528 --&gt;

== Tech News: 2025-29 ==

&lt;section begin=&quot;technews-2025-W29&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/29|Translations]] are available.

'''Updates for editors'''
* [[mw:Special:MyLanguage/Help:TemplateData/Template discovery#Featured templates|Featured templates]], a new feature related to [[m:Special:MyLanguage/Community Wishlist/Focus areas/Template recall and discovery|Template Recall and Discovery]] will be deployed this week to all Wikimedia projects: With this feature, editors will be able to quickly access a list of templates that are likely to be useful. These templates will be displayed in a list, under the &quot;featured&quot; tab of the template discovery interface. Administrators can define the list via the Community Configuration interface. The feature fulfills a request by the community [[m:Special:MyLanguage/Community Wishlist/Wishes/Easy access Templates|through the Community Wishlist]]. [https://phabricator.wikimedia.org/T367428][https://phabricator.wikimedia.org/T392896]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:31}} community-submitted {{PLURAL:31|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the request to add Malayalam fonts in the [[oldWikisource:Special:MyLanguage/Wikisource:WS Export|Wikisource Book Export Tool]] was resolved and now, the rendering of Malayalam letters in exported Wikisource books are accurate. [https://phabricator.wikimedia.org/T374457]

'''Updates for technical contributors'''
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.10|MediaWiki]]

'''In depth'''
* Developers, designers, and all Wikimedians are invited to [https://phabricator.wikimedia.org/project/board/7953/ submit a project idea] for the Wikimania Hackathon 2025. Read [https://diff.wikimedia.org/2025/06/30/call-for-projects-wikimania-hackathon-2025-is-coming-to-nairobi/ this Diff blog post] for more details.

'''Meetings and events'''
* [[m:WikiIndaba conference 2025|WikiIndaba 2025]] scholarship application and program submission is open until 23:59 GMT on July 20. WikiIndaba is a regional conference for African Wikimedians both on the continent and in the diaspora to unite and grow together. Submit [https://docs.google.com/forms/d/e/1FAIpQLSdJTv68R1OPASXXDfpIl8EWiMLTM-TDwh6_5gNVvFuWccFZ2Q/viewform your scholarship application] and [https://ee.kobotoolbox.org/x/BI3omIfH program proposal] now!
* [https://br.wikimedia.org/wiki/WikiCon_Brasil_2025 WikiCon Brasil 2025] will take place on July 19-20 in Salvador, Bahia, Brazil. The Brazilian community members are encouraged to register and attend!

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/29|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W29&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:10, 14 July 2025 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=28980963 --&gt;

== Wikipedia translation of the week: 2025-30 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Vespa analis]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Plumpy hornet on the ground - 1.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''Vespa analis''''', the yellow-vented hornet, is a species of common hornet found in Southeast Asia 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:28, 21 July 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=28984647 --&gt;

== Tech News: 2025-30 ==

&lt;section begin=&quot;technews-2025-W30&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/30|Translations]] are available.

'''Updates for editors'''
* The Translation Suggestions feature in the [[mw:Special:MyLanguage/Content translation|Content Translation tool]] now has another level of article filters added to the &quot;[https://en.wikipedia.org/w/index.php?title=Special:ContentTranslation&amp;filter-type=automatic&amp;filter-id=previous-edits&amp;active-list=suggestions&amp;from=en&amp;to=fi#/ ... More]&quot; category. Translators who use the Suggestions feature can now select and receive article suggestions that are customized to geographical locations of their interest using the new &quot;{{int:Cx-sx-suggestions-filters-tab-regions}}&quot; filter. [https://phabricator.wikimedia.org/T113257]
* Administrators can now limit &quot;Add a Link&quot; to newcomers. The [[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|&quot;Add a Link&quot;]] Structured Task [[mw:Special:MyLanguage/Growth/Constructive activation experimentation#Enwiki A/B test &amp; &quot;Add a Link&quot; Improvements (Wiki Experiences 1.2.11 &amp; 1.2.16)|helps new account holders start editing]], but some communities have requested the ability to restrict it to its intended audience: newcomers. Administrators can configure this setting within the [[Special:CommunityConfiguration/GrowthSuggestedEdits|Community Configuration]] feature.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:29}} community-submitted {{PLURAL:29|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* For AbuseFilter editors on [[phab:T392144|some wikis]], it is now possible to filter edits based on the RevertRisk score of the edit being attempted. It is only populated if the action being evaluated is an edit. For more information, please see the [[mw:Special:MyLanguage/Extension:ORES/AbuseFilter variables#What variables are available for use|ORES/AbuseFilter variables]] documentation.
* The [[mw:Special:MyLanguage/Beta Cluster|Beta Cluster]] wikis have [[listarchive:list/wikitech-l@lists.wikimedia.org/thread/YDABPV75LADRQCXMJAFWUP256N4EQ25B/|been moved]] from &lt;code dir=ltr&gt;beta.wmflabs.org&lt;/code&gt; to &lt;code dir=ltr&gt;beta.wmcloud.org&lt;/code&gt;. Users may need to update URLs in any tools, or in their password managers. Any related issues can be [[phab:T289318|reported in the task]].
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.11|MediaWiki]]

'''Meetings and events'''
* [[m:Special:MyLanguage/WikiCite 2025|WikiCite 2025]] will take place from 29–31 August, both online and in-person in Bern, Switzerland. The event's goals are to reconnect communities, institutions, and individuals working with open citations, bibliographic data, and the Wikidata/Wikibase ecosystem. Registration is open and the call for proposals will be announced soon. [https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/KQZUG3ETKLBWPBYSB2YAWZIRPWHS24TG/]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/30|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W30&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:43, 21 July 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29005283 --&gt;

== Wikipedia translation of the week: 2025-31 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Fernando de Noronha Marine National Park]]'''&lt;br /&gt; &lt;small&gt;''([[:pt:Parque Nacional Marinho de Fernando de Noronha]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Baía dos Porcos - Fernando de Noronha (32811749914).jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Fernando de Noronha Marine National Park''' (Portuguese: Parque Nacional Marinho de Fernando de Noronha) is a national park in the state of Pernambuco, Brazil. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:40, 28 July 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29047614 --&gt;

== Tech News: 2025-31 ==

&lt;section begin=&quot;technews-2025-W31&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/31|Translations]] are available.

'''Weekly highlight'''
* The Community Tech team will be focusing on wishes related to Watchlists and Recent Changes pages, over the next few months. They are looking for feedback. Please [[m:Special:MyLanguage/Community Wishlist/Updates#July 24, 2025: Watchlists and Recent Changes pages|read the latest update]], and if you have ideas, please [[m:Special:MyLanguage/Community Wishlist|submit a wish]] on the topic.

'''Updates for editors'''
* The Wikimedia Commons community has decided to block [[:mw:Special:MyLanguage/Upload dialog|cross-wiki uploads]] to Wikimedia Commons, for all users without autoconfirmed rights on that wiki, starting on August 16. This is because of [[:c:Commons:Cross-wiki media upload tool/History|widespread problems]] related to files that are uploaded by newcomers. Users who are affected by this will get an error message with a link to the less restrictive UploadWizard on Commons. Please help translating the [[:c:Special:MyLanguage/MediaWiki:Abusefilter-disallowed-cross-wiki-upload|message]] or give feedback on the message text. Please also update your local help pages to explain this restriction. [https://phabricator.wikimedia.org/T370598]
* On wikis with temporary accounts enabled and Meta-Wiki, administrators may now set up a footer for the Special:Contributions pages of temporary accounts, similar to those which can be shown on IP and user-account pages. They may do it by creating the page named &lt;code dir=ltr&gt;MediaWiki:Sp-contributions-footer-temp&lt;/code&gt;. [https://phabricator.wikimedia.org/T398347]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:21}} community-submitted {{PLURAL:21|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.12|MediaWiki]]

'''Meetings and events'''
* [[wmania:Special:MyLanguage/2025:Wikimania|Wikimania 2025]] will run from August 6–9. The [https://wikimedia.eventyay.com/talk/wikimania2025/schedule/ program is available] for you to plan which sessions you want to attend. Most sessions will be live-streamed, with exceptions for those that show the &quot;no camera&quot; icon. If you are joining online to watch live-streams and use the interactive features, please [[wmania:Special:MyLanguage/2025:Registration|register]] for a free virtual ticket. For example, you may be interested in technical sessions such as:
** [https://wikimedia.eventyay.com/talk/wikimania2025/talk/KFEFVG/ Temporary Accounts: Enhancing privacy for our unregistered editors]
** [https://wikimedia.eventyay.com/talk/wikimania2025/talk/TVCVAB/ Building a Sustainable Future for Wikimedia Contributors]
** [https://wikimedia.eventyay.com/talk/wikimania2025/talk/WTRQCJ/ A dozen visions for wikitext!]
** [https://wikimedia.eventyay.com/talk/wikimania2025/talk/8YKKP9/ Coordinate Across Stakeholders with the Product and Technology Advisory Council]
* The [[mw:Special:MyLanguage/MediaWiki Users and Developers Conference Fall 2025|MediaWiki Users and Developers Conference, Fall 2025]] will be held 28–30 October 2025 in Hanover, Germany. This event is organized by and for the third-party MediaWiki community. You can propose sessions and register to attend.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/31|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W31&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:27, 29 July 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29051727 --&gt;

== Wikipedia translation of the week: 2025-32 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Xie Zhiliu]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Xie Zhiliu''' (Chinese: 谢稚柳; 1910–1997) was a leading traditional painter, calligrapher, and art connoisseur of modern China. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:21, 4 August 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29077280 --&gt;

== Tech News: 2025-32 ==

&lt;section begin=&quot;technews-2025-W32&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/32|Translations]] are available.

'''Updates for editors'''
* Editors can now enable the [[mw:Special:MyLanguage/Product Safety and Integrity/Anti-abuse signals/User Info|User Info card]]. This feature adds an icon next to usernames on history pages and similar user-contribution log pages. When you tap or click on the icon, it displays data related to that user account such as the number of edits, reverted edits, blocks, and more. It's part of a broader project to make it easier for moderators to evaluate account trustworthiness. The feature can be enabled in [[testwiki:Special:GlobalPreferences#mw-prefsection-rendering|your global preferences]], and later this week it will be available in local preferences. [https://phabricator.wikimedia.org/T386439]
* Everybody is invited to share comments on [[m:Special:MyLanguage/CampaignEvents/Collaborative contributions|Collaborative Contributions]], a project recently launched by the [[m:Special:MyLanguage/Connection Team|Connection team]]. The project aims to create a new way to display the impact of collaborative editing activities (such as edit-a-thons, backlog drives, and WikiProjects) on the wikis. Post your comments on the [[m:Talk:CampaignEvents/Collaborative contributions|project talk page]]. [https://phabricator.wikimedia.org/T378035]
* Administrators can now define the default block duration for temporary accounts. To do that, they need to create a page named &lt;code dir=ltr&gt;MediaWiki:Ipb-default-expiry-temporary-account&lt;/code&gt; and use a value defined in &lt;code dir=ltr&gt;MediaWiki:Ipboptions&lt;/code&gt;. This allows administrators to easily block temporary accounts for 90 days, which is functionally equivalent to an indefinite block. The advantage of this solution is that it does not clutter Special:BlockList. [[mw:Special:MyLanguage/Manual:Block and unblock#Default block duration options|More documentation]] is available. [https://phabricator.wikimedia.org/T398626]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* Gadgets can now include &lt;code dir=ltr&gt;.vue&lt;/code&gt; files. This makes it easier to develop modern user interfaces using [[mw:Vue.js|Vue.js]], in particular using [[mw:Special:MyLanguage/Codex|Codex]], the official design system of Wikimedia. [[wmdoc:codex/latest/icons/overview.html|Codex icons]] can be loaded through the gadget definition. [[mw:Special:MyLanguage/Extension:Gadgets#Pages|The documentation]] has examples. For user scripts that use Vue.js, an [[mw:API:CodexIcons|API module]] now exists to load Codex icons. [https://phabricator.wikimedia.org/T340460][https://phabricator.wikimedia.org/T311099]
* Module developers can now use a [[mw:Help:Extension:Translate/Message Bundles/Lua reference|Lua interface]] to simplify the preparation of Lua modules for translation on Meta-Wiki. This improvement makes it easier for translators to find and edit module strings without dealing with raw Lua code. It helps prevent mistakes that could break the module during translation. Module developers and translators are invited to [[commons:File:Translatable modules video demo July 2025.webm|watch the demo video]], read more about [[mw:Special:MyLanguage/Translatable modules|translatable modules]] to understand how it works, refer to Meta-Wiki's [[m:Module:User Wikimedia project|Module:User Wikimedia project]] for example usage, and [[mw:Talk:Translatable modules|share their feedback]] on how well it addresses the challenges in their workflow. The interface still has some performance issues, so it should not be used in widely used modules yet. [https://phabricator.wikimedia.org/T359918]
* Developers of external tools that connect to Wikimedia pages must set a user-agent that complies with [[foundation:Special:MyLanguage/Policy:Wikimedia Foundation User-Agent Policy|the user-agent policy]]. This policy will start to be more strongly enforced in August because of external crawlers that are [[diffblog:2025/04/01/how-crawlers-impact-the-operations-of-the-wikimedia-projects/|overusing]] Wikimedia's resources. Tools that are hosted on Wikimedia's Toolforge or Cloud VPS will not be affected by this for now, but should still set a user-agent. [[phab:T400119|More technical details are available]], and related questions are welcome in that task.
* Parsoid Read Views is going to be rolling out to some smaller Wikipedias over the next few weeks, following the successful transition of Wikivoyages and Wiktionaries to Parsoid Read Views. For more information, see the [[mw:Special:MyLanguage/Parsoid/Parser Unification|Parsoid/Parser Unification]] project page. [https://phabricator.wikimedia.org/project/profile/7694/]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.13|MediaWiki]]

'''Meetings and events'''
* [[wmania:Special:MyLanguage/2025:Wikimania|Wikimania 2025]] will run from August 6–9. The [https://wikimedia.eventyay.com/talk/wikimania2025/schedule/ program is available] for you to plan which sessions you want to attend. Most sessions will be live-streamed, with exceptions for those that show the &quot;no camera&quot; icon. If you are joining online to watch live-streams and use the interactive features, please [[wmania:Special:MyLanguage/2025:Registration|register]] for a free virtual ticket. For example, you may be interested in technical sessions such as:
** [https://wikimedia.eventyay.com/talk/wikimania2025/talk/GEH9DH/ Wikimedia’s knowledge infrastructure in a changing internet: Establishing sustainable pathways for content reuse]
** [https://wikimedia.eventyay.com/talk/wikimania2025/talk/7ELN9Q/ Wikifunctions is coming soon to a wiki near you!]
** [https://wikimedia.eventyay.com/talk/wikimania2025/talk/ZMGVJV/ Shaping the Future of Wikipedia’s Reader Experience]
** [https://wikimedia.eventyay.com/talk/wikimania2025/talk/KCKTFZ/ Making Wikipedia More Readable: What Comes Next]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/32|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W32&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 03:41, 5 August 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29083927 --&gt;

== Wikipedia translation of the week: 2025-33 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Lethocerus patruelis]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Lethocerus patruelis.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''Lethocerus patruelis''''' is a giant water bug in the family Belostomatidae. It is native to southeastern Europe, through Southwest Asia, to Pakistan, India and Burma. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:20, 11 August 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29085671 --&gt;

== Tech News: 2025-33 ==

&lt;section begin=&quot;technews-2025-W33&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/33|Translations]] are available.

'''Updates for editors'''
* The WikiEditor toolbar now includes [[mw:Special:MyLanguage/Help:Extension:WikiEditor#Keyboard shortcuts|its keyboard shortcuts]] in the tooltips for its buttons. This will help to improve the discoverability of this feature. [https://phabricator.wikimedia.org/T400583]
* The [[m:Special:MyLanguage/Product and Technology Advisory Council|Product and Technology Advisory Council]] published a set of [[m:Special:MyLanguage/Product and Technology Advisory Council/August 2025 draft PTAC proposals for feedback|proposed experiments]] the Wikimedia Foundation can try to improve communication with community. Feedback on the proposals are welcomed until August 22 on [[m:Talk:Product and Technology Advisory Council/August 2025 draft PTAC proposals for feedback|this talk page]].
* The search bar on the Minerva skin (mobile) has been updated to use the same type-ahead search component that is used on the Vector 2022 skin. There are no changes in search functionality but there are minor visual changes. Specifically, the close-search button has been changed from an &quot;X&quot; to a back arrow. This helps to distinguish it from the other &quot;X&quot; button that is used to clear any text. [https://phabricator.wikimedia.org/T393944]
* Editors on some wikis will see a new toggle for &quot;Group results by page&quot; on watchlist, related changes, and recent changes pages. This is [[mw:Special:MyLanguage/Moderator Tools/Watchlist/Experiment|an A/B experiment]] that is planned to start on August 11, and will run for 3–6 weeks on the Bengali, Chinese, Czech, French, Greek, Portuguese, and Urdu Wikipedias. The experiment will examine how making this feature more discoverable might affect editors' ability to find the edits they are looking for. [https://phabricator.wikimedia.org/T396789]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:31}} community-submitted {{PLURAL:31|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* The multiwiki datasets of [[:wikt:en:Module:Unicode data|Unicode data]] have been moved to [[c:Category:Unicode Module Datasets|Category:Unicode Module Datasets]] on Wikimedia Commons, to follow the idea of &quot;One common data source, multiple local wikis&quot;. Most wikis have been updated to use the Commons version. You can ask questions at [[c:Category talk:Unicode Module Datasets|the talkpage]]. [https://en.wiktionary.org/wiki/Module_talk:Unicode_data#Data_from_commons]
* Lua code can add warnings when something is wrong, by using the &lt;code dir=ltr&gt;mw.addWarning()&lt;/code&gt; function. It is now possible to add more than one warning, instead of new warnings replacing old ones. If you maintain a Lua module that used warnings, you should check it still works as expected. [https://phabricator.wikimedia.org/T398390]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.14|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/33|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W33&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:30, 11 August 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29106516 --&gt;

== Wikipedia translation of the week: 2025-34 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Ikiza]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:CIA map of Burundi and surrounding countries during 1972 killings.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Ikiza''' (variously translated from Kirundi as the Catastrophe, the Great Calamity, and the Scourge), or the Ubwicanyi (Killings), was a series of mass killings—often characterised as a genocide—which were committed in Burundi in 1972 by the Tutsi-dominated army and government, primarily against educated and elite Hutus who lived in the country. Conservative estimates place the death toll of the event between 100,000 and 150,000 killed, while some estimates of the death toll go as high as 300,000. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:43, 18 August 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29115447 --&gt;

== Tech News: 2025-34 ==

&lt;section begin=&quot;technews-2025-W34&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/34|Translations]] are available.

'''Updates for editors'''
* Later this week, people who are logged-in and have the &quot;[[mw:Special:MyLanguage/Talk pages project/Feature summary|Discussion tools]]&quot; [[Special:Preferences#mw-prefsection-betafeatures|Beta Feature]] enabled will gain the ability to &quot;Thank&quot; individual comments directly from talk pages, rather than needing to navigate to page history. [[mw:Special:MyLanguage/Talk pages project/Feature summary#Comment actions|Learn more about this feature]]. [https://phabricator.wikimedia.org/T400849]
* An A/B test comparing two versions of the desktop donate link launched on testwiki on 12 August and on English Wikipedia 14 August for 0.1% of logged out users on the desktop site. The experiment will run for three weeks, ending on 12 September. [https://phabricator.wikimedia.org/T395716]
* An A/A test to measure the baseline for reader retention was launched 12 August using [[wikitech:Experimentation Lab|Experimentation Lab]]. This measures the percentage of users who revisit a wiki after their initial visit over a 14-day period. No visual changes are expected. The experiment will run through 31 August. [https://phabricator.wikimedia.org/T399227]
* Five new wikis have been created:
** a {{int:project-localized-name-group-wikisource/en}} in [[d:Q34057|Tagalog]] ([[s:tl:|&lt;code&gt;s:tl:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T388639]
** a {{int:project-localized-name-group-wikisource/en}} in [[d:Q36213|Madurese]] ([[s:mad:|&lt;code&gt;s:mad:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T391747]
** a {{int:project-localized-name-group-wikipedia/en}} in [[d:Q3450749|Rakhine]] ([[w:rki:|&lt;code&gt;w:rki:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T392490]
** a {{int:project-localized-name-group-wikibooks/en}} in [[d:Q13324|Minangkabau]] ([[b:min:|&lt;code&gt;b:min:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T395452]
** a {{int:project-localized-name-group-wiktionary/en}} in [[d:Q7598268|Standard Moroccan Amazigh]] ([[wikt:zgh:|&lt;code&gt;wikt:zgh:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T399684]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:46}} community-submitted {{PLURAL:46|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.15|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/34|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W34&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:39, 19 August 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29127690 --&gt;

== Wikipedia translation of the week: 2025-35 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Corallite]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Recent azooxanthellate Scleractinia (Cnidaria, Anthozoa) - ZooKeys-227-001-g004.jpeg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
A '''corallite''' is the skeletal cup, formed by an individual stony coral polyp, in which the polyp sits and into which it can retract. The cup is composed of aragonite, a crystalline form of calcium carbonate, and is secreted by the polyp. Corallites vary in size, but in most colonial corals they are less than 3 mm (0.12 in) in diameter. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:18, 25 August 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29115447 --&gt;

== Tech News: 2025-35 ==

&lt;section begin=&quot;technews-2025-W35&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/35|Translations]] are available.

'''Updates for editors'''
* [[File:Octicons-gift.svg|12px|link=|class=skin-invert|Wishlist item]] [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Template authors can now use additional CSS properties, since the CSS sanitizer used by [[mw:Special:MyLanguage/Help:TemplateStyles|TemplateStyles]] was updated. For example: &lt;code&gt;width: fit-content&lt;/code&gt;; &lt;code&gt;ruby-align&lt;/code&gt;; relative units such as &lt;code&gt;lh&lt;/code&gt;; and custom strings in &lt;code&gt;list-style-type&lt;/code&gt;. These improvements are a [[m:Special:MyLanguage/Community Wishlist/Wishes/Allow use of modern CSS in templates by updating the TemplateStyles CSS sanitizer|Community Wishlist wish]]. [https://phabricator.wikimedia.org/T271958][https://phabricator.wikimedia.org/T277755][https://phabricator.wikimedia.org/T293633][https://phabricator.wikimedia.org/T295088][https://phabricator.wikimedia.org/T326906][https://phabricator.wikimedia.org/T340057][https://phabricator.wikimedia.org/T360725][https://phabricator.wikimedia.org/T371809][https://phabricator.wikimedia.org/T375344][https://phabricator.wikimedia.org/T394619]
* On large wikis, the default time period to display edits from, within the Special:RecentChanges page, has been changed from 7 days to 1 day. This is part of a performance improvement project. This should have no user-facing impact due to the quantity of edits on these wikis. [https://phabricator.wikimedia.org/T399455]
* Administrators can now access the [[{{#special:BlockedExternalDomains}}]] page from the [[{{#special:CommunityConfiguration}}]] list page. This makes it easier to find. [https://phabricator.wikimedia.org/T393240]
* Wikimedia Commons videos were not shown in the Videos tab in Google Search. The problem was investigated and reported to Google who have now fixed the issue. [https://phabricator.wikimedia.org/T396168][https://meta.wikimedia.org/wiki/Community_Wishlist/Wishes/Do_something_about_Google_%26_DuckDuckGo_search_not_indexing_media_files_and_categories_on_Commons] 
* One new wiki has been created: a {{int:project-localized-name-group-wiktionary/en}} in [[d:Q33014|Betawi]] ([[wikt:bew:|&lt;code&gt;wikt:bew:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T402130]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:39}} community-submitted {{PLURAL:39|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* Two fields of the [[mw:Special:MyLanguage/Manual:Recentchanges table|recentchanges database table]] are being removed. &lt;code&gt;rc_new&lt;/code&gt; and &lt;code&gt;rc_type&lt;/code&gt; are being removed in favor of &lt;code&gt;rc_source&lt;/code&gt;. Queries to these older fields will start to fail starting this week and developers should use &lt;code&gt;rc_source&lt;/code&gt; instead. These older fields were deprecated over 10 years ago and should not be in use. This is part of work to improve the performance and stability of queries to the recentchanges table. [https://phabricator.wikimedia.org/T400696] 
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.16|MediaWiki]]

'''In depth'''
* The latest quarterly [[mw:Special:MyLanguage/Wikimedia Language and Product Localization/Newsletter/2025/July|Language and Internationalization Newsletter]] is now available. This edition includes: support for new languages in MediaWiki and translatewiki; the start of the Language Onboarding and Development project to help support the growth of new and small wikis; updates on research projects; and more.

'''Meetings and events'''
* The next [[mw:Special:MyLanguage/Wikimedia Language and Product Localization/Community meetings#29 August 2025|Language Community Meeting]] is happening soon, August 29th at [https://zonestamp.toolforge.org/1756479600 15:00 UTC]. This week's meeting will cover: the Avro keyboard developers from Wikimedia Bangladesh, who were recently awarded a national award for their contributions to this keyboard; and other topics. 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/35|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W35&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 00:13, 26 August 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29175124 --&gt;

== Wikipedia translation of the week: 2025-36 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Diksam Plateau]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Dixam plateau (6407168437).jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Diksam Plateau''' or Dixam Plateau (Arabic: دكسم) is a limestone plateau in Socotra, Yemen. The Firmihin forest, located east of the Dirhur canyon within the plateau, has the highest concentration of Dragon's Blood Trees on the entire island. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:40, 1 September 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29195081 --&gt;

== Tech News: 2025-36 ==

&lt;section begin=&quot;technews-2025-W36&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/36|Translations]] are available.

'''Weekly highlight'''
* The Editing team wants to compile a list of templates, jargon terms, and policies used in edit summaries when a copyright violation is removed. This will help them identify the number of edits reverted due to copyright issues. We invite community members from the following Wikis to list these terms in [[Phab:T402601|T402601]], or to share their list with [[User:Trizek (WMF)|Trizek_(WMF)]]: {{int:project-localized-name-arwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-cswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-dewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-enwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-eswiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-fawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-frwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-hewiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-idwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-itwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-jawiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kowiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-nlwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-plwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ptwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-trwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ukwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-viwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-zhwiki/en}}. This project is open until September 9th 2025.

'''Updates for editors'''
* The [[mw:Special:MyLanguage/Help:Extension:CampaignEvents|CampaignEvents extension]] has been enabled for all Wikisources. The extension makes it easier to organize and participate in collaborative activities, like edit-a-thons and WikiProjects, on the wikis. The extension has three features: [[m:Special:MyLanguage/Event Center/Registration|Event Registration]], [[m:Special:MyLanguage/CampaignEvents/Collaboration list|Collaboration List]], and [[m:Special:MyLanguage/Connection Team/Invitation list|Invitation List]]. To request the extension for your wiki, visit the Deployment information page. [https://meta.wikimedia.org/wiki/CampaignEvents/Deployment_status#How_to_Request_the_CampaignEvents_Extension_for_your_wiki]
* The lists in the footer of the editing interface, such as &quot;Templates used on this page,&quot; will now be organized into columns when there is enough space. This enhancement minimizes scrolling when editing lengthy articles on Wikipedia. [https://phabricator.wikimedia.org/T401066]
* On September 3rd, 2025 we will increase the sampling percentages of our [[mw:Special:MyLanguage/Moderator Tools/Watchlist/Experiment#Scope of the experiment|group by toggle experiment]] of the &lt;code&gt;Special:RecentChanges&lt;/code&gt;, &lt;code&gt;Special:Watchlist&lt;/code&gt;, and &lt;code&gt;Special:RelatedChanges&lt;/code&gt; pages on the Chinese, French, and Portuguese Wikipedias to 100 percent, allowing more editors to be part of this experiment. This adjustment is intended to ensure we have sufficient data to make informed decisions when evaluating the experiment results. [https://phabricator.wikimedia.org/T402958][https://phabricator.wikimedia.org/T396789]
* Upon clicking an empty search bar, logged-out users will see suggestions of articles for further reading on English Wikipedia beginning the week of September 22. The feature will be available on both desktop and mobile. All non-English wikis received this change in June and July. The goal is to make it easier for users to find articles. [[mw:Special:MyLanguage/Reading/Web/Content Discovery Experiments/Search Suggestions|Learn more]].
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:37}} community-submitted {{PLURAL:37|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.17|MediaWiki]]

'''In depth'''
* Wikifunctions now has a new capability called &quot;lightweight enumeration types&quot;, an enumeration type is simply a fixed set of values that's in the type's definition. This capability makes it quick and easy to define such a type, and allows for the reuse of values that are already present in Wikidata. Here is [[f:Special:MyLanguage/Wikifunctions:Status updates/2025-07-19|a newsletter]] to learn more.
* The latest [[mw:Special:MyLanguage/Readers/Newsletter updates#August 2025: Newsletter #1|Readers Newsletter]] is now available. This edition includes: the formation of two new teams — Reader Growth and Reader Experience; insights into declining pageviews and account creations; highlights from the Wikimania Nairobi panel on improving the reading experience; upcoming experiments to engage new and existing readers; and more.

'''Meetings and events'''
* Spotlight on some Wikimania 2025 Sessions:
** Identifying AI-generated text by searching for ISBNs whose checksums fail: Mathias Schindler of WMDE [https://www.youtube.com/watch?v=Dw9o8Lsl974&amp;t=15910s shared tools to help communities search for these].
** [https://wikimedia.eventyay.com/talk/wikimania2025/talk/TCHZKH/ La durabilité du mouvement Wikimedia face aux défis actuels et futurs]: This session explored how Wikimedia can stay a trusted source of knowledge in the age of generative AI, information overload, and disinformation.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/36|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W36&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:51, 1 September 2025 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29196010 --&gt;

== Wikipedia translation of the week: 2025-37 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Ttongsul]]'''&lt;br /&gt; &lt;small&gt;''([[:ja:トンスル]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Ttongsul (imitation).jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
Il '''ttongsul''' (똥술), o vino di feci, è una tradizionale preparazione medicinale coreana con gradazione alcolica al 9% a base di feci, solitamente umane e preferibilmente di bambino. Nato probabilmente traendo spunto dalla medicina tradizionale cinese, nelle credenze popolari il vino di feci avrebbe proprietà benefiche per molti tipi di malesseri: sarebbe un rimedio per dolori muscolari, ustioni, infiammazioni, epilessia e fratture ossee.

Sebbene alcuni media occidentali abbiano in passato riportato che questa bevanda sia diffusa tra la popolazione coreana, al giorno d'oggi un numero molto limitato di persone ne fa uso, dopo aver subito un declino di popolarità nei secoli scorsi, tanto che la maggioranza dei giovani coreani non ne ha mai sentito parlare.  

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:28, 8 September 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29195081 --&gt;

== Tech News: 2025-37 ==

&lt;section begin=&quot;technews-2025-W37&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/37|Translations]] are available.

'''Weekly highlight'''
* The Editing team is working on a new check: [[mw:Special:MyLanguage/Paste check|Paste check]]. This check informs newcomers who paste text into Wikipedia that the content might not be accepted. This check is an effort to increase the likelihood that the new content people are adding to Wikipedia is aligned with the Movement's commitment to offering information under a free content license. This check will soon be tested at a few wikis. If your community is interested in this test, please [[phab:T403680|tell us in this task]], or [[mw:Talk:Edit check|contact the team]].

'''Updates for editors'''
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] Later this week, users of the &quot;{{int:codemirror-beta-feature-title}}&quot; [[Special:Preferences#mw-prefsection-betafeatures|beta feature]] will be able to use a [[w:en:Lint (software)|linting tool]] to see errors or other potential problems in wikitext in real time. See the [[mw:Special:MyLanguage/Help:Extension:CodeMirror#Linting|help page for more information]]. [https://phabricator.wikimedia.org/T381577]
* [[File:Octicons-tools.svg|12px|link=|class=skin-invert|Advanced item]] When browsing a wiki (like &lt;code dir=ltr&gt;en.wikipedia.org&lt;/code&gt;), the software responds in one of two ways: a desktop page, or a redirect to a mobile version on an &quot;m&quot; domain (like &lt;code dir=ltr&gt;en.m.wikipedia.org&lt;/code&gt;). Over the next three weeks, MediaWiki will start displaying the mobile version to mobile devices directly on the standard domain, without this redirect. This change does not affect existing m-dot URLs, or the &quot;Desktop view&quot; opt-out. [[mw:Requests for comment/Mobile domain sunsetting/2025 Announcement|Learn more]]. [https://phabricator.wikimedia.org/T214998]
* When an edit changes the categories of a page, the changes to the category membership counts are now happening asynchronously. This improves the speed of saving edits, especially when moving many pages to or from the same category, and reduces the risk of site outages, but it means that the counts can show outdated information for a few minutes. [https://phabricator.wikimedia.org/T365303] 
* Edits on Wikidata to qualifiers (properties and values) and references (properties and values) in a Wikidata item statement will now not add entries to the RecentChanges or Watchlist pages on all other Wikis. This is a temporary change to improve performance while other solutions are created. Wikidata's own pages remain unchanged. [[m:Wikidata For Wikimedia Projects/Reduce change propagation noise#Phase 1: Turn off (temporarily) Qualifiers and References Wikidata edits to the Recent Changes tables|Learn more]]. [https://phabricator.wikimedia.org/T401286][https://phabricator.wikimedia.org/T400698]
* Japanese-language wikis have had a major upgrade to the way that search works. The new search should generally give more accurate and more relevant search results. [https://phabricator.wikimedia.org/T318269]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:31}} community-submitted {{PLURAL:31|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.18|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/37|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W37&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 01:15, 9 September 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29238161 --&gt;

== Wikipedia translation of the week: 2025-38 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Pak Kum-chol]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Pak Kum-chol in 1961 (cropped).jpg|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Pak Kum-chol''' was a North Korean politician. Having been a guerrilla during the anti-Japanese struggle, he became a high-ranking politician after the liberation of Korea. Pak aligned himself with his former guerrilla brothers in arms from the Kapsan Operation Committee to form a faction within the ruling Workers' Party of Korea (WPK) called the &quot;Kapsan faction&quot;. This faction sought to replace Kim Il Sung with Pak. Kim retaliated by purging the faction in 1967 in what is known as the Kapsan faction incident. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:18, 15 September 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29249252 --&gt;

== Tech News: 2025-38 ==

&lt;section begin=&quot;technews-2025-W38&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/38|Translations]] are available.

'''Updates for editors'''
* References lists that are made using the &lt;code dir=ltr&gt;&lt;nowiki&gt;&lt;references/&gt;&lt;/nowiki&gt;&lt;/code&gt; [[mw:Special:MyLanguage/Help:Cite#references-tag|tag]] will now automatically display with columns in Vector 2022 when readers are using its 'standard' settings for text-size and page-width. [https://phabricator.wikimedia.org/T334941]
* Starting in the week of October 6, on [[gitiles:operations/mediawiki-config/+/a2d2aaab9ace84280dd2f4c70a33bb69cd73850f/dblists/small.dblist|small wikis]] and [[gitiles:operations/mediawiki-config/+/a2d2aaab9ace84280dd2f4c70a33bb69cd73850f/dblists/medium.dblist|medium wikis]] that have the [[mw:Special:MyLanguage/Help:Extension:CampaignEvents|CampaignEvents extension]] enabled, all autoconfirmed users will be able to use [[m:Special:MyLanguage/Event Center/Registration|Event Registration]] as an organizer. No changes will be made for [[gitiles:operations/mediawiki-config/+/a2d2aaab9ace84280dd2f4c70a33bb69cd73850f/dblists/large.dblist|large wikis]] unless requested in Phabricator. This change is being made to make it easier for more people to use Event Registration, especially on wikis that are less likely to have policies related to the Event Organizer right. [[m:Special:MyLanguage/CampaignEvents/Proposal to grant autoconfirmed users on small and medium wikis the organizer access to the event registration tool|Learn more]].
* Users that search using regular expressions (regex) can now use additional features including:
** for the &lt;code dir=ltr&gt;intitle:&lt;/code&gt; keyword: [[mw:Special:MyLanguage/Help:CirrusSearch#Metacharacters|metacharacters]] for start-of-line (&lt;code dir=ltr&gt;^&lt;/code&gt;) and end-of-line (&lt;code dir=ltr&gt;$&lt;/code&gt;) anchors [https://phabricator.wikimedia.org/T317599]
** for both &lt;code dir=ltr&gt;intitle:&lt;/code&gt; and &lt;code dir=ltr&gt;insource:&lt;/code&gt; keywords: shorthand [[mw:Special:MyLanguage/Help:CirrusSearch#Character_Classes|character classes]] for digits (&lt;code dir=ltr&gt;\d&lt;/code&gt;), whitespace (&lt;code dir=ltr&gt;\s&lt;/code&gt;), and word characters (&lt;code dir=ltr&gt;\w&lt;/code&gt;); and [[mw:Special:MyLanguage/Help:CirrusSearch#Escape codes|escape codes]] for line feed (&lt;code dir=ltr&gt;\r&lt;/code&gt;), newline (&lt;code dir=ltr&gt;\n&lt;/code&gt;), tab (&lt;code dir=ltr&gt;\t&lt;/code&gt;), and unicode (e.g. &lt;code dir=ltr&gt;\uHHHH&lt;/code&gt;). [https://phabricator.wikimedia.org/T403212]
* When you search for text that looks like an IP, the system will now show search results. It used to take you to the contributions for that IP instead of showing search results. [https://phabricator.wikimedia.org/T306325]
* [[m:Special:MyLanguage/Tech/Server switch|All wikis will be read-only]] for a few minutes on September 24. This is planned at [https://zonestamp.toolforge.org/1758726000 15:00 UTC]. This is for the datacenter server switchover backup tests which happen twice a year. You can [[diffblog:2025/03/12/hear-that-the-wikis-go-silent-twice-a-year/|read more about the background and details of this process on the Diff blog]].
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:24}} community-submitted {{PLURAL:24|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a bug was fixed that affected users who used the page-tabs to switch from wikitext editing of a section into the visualeditor. [https://phabricator.wikimedia.org/T401043]

'''Updates for technical contributors'''
* The MediaWiki Interfaces team is redesigning the Wikimedia REST API Sandbox with Codex. If you have feedback on improvements for the API documentation or what makes developer experiences smooth (or frustrating), you’re invited to [https://calendar.google.com/calendar/u/0/appointments/schedules/AcZssZ2aZzbXeQvjOF7gB1fJXiwAYemQjKf4sXNaRODPA7_obFyNBwkzNkoVCoTF-aeov89kIjXHbCQm join an upcoming discovery interview], or [[mw:MediaWiki Interfaces Team/Developer Feedback/Wikimedia Web APIs|leave feedback onwiki]]. [[listarchive:list/wikitech-l@lists.wikimedia.org/thread/C4FBAOA57PH6G5ORVMAUF5TGYBLZDU5Q/|Learn more]].
* Edits to Wikidata aliases (an alternative name for an item or a property) will now be shown in RecentChanges and Watchlist entries on other wikis less often, reducing unnecessary notifications. This will reduce the overall quantity of 'noisy' entries. Wikidata's own pages remain unchanged. [[m:Wikidata For Wikimedia Projects/Reduce change propagation noise#Phase 1: More granular Alias tracking|Learn more]]. [https://phabricator.wikimedia.org/T401288]
* The new [https://www.unicode.org/versions/Unicode17.0.0/ Unicode 17.0] version has been released. The [[:c:Category:Unicode Module Datasets|datasets on Commons]] for the [[:d:Q39301585|Module:Unicode data]] have been updated. Wikipedias that do not use the Commons datasets should either update their own data or switch to the Commons datasets.
* Users of the [[m:Special:MyLanguage/Wikimedia Enterprise|Wikimedia Enterprise]] Structured Contents endpoints can now access [https://enterprise.wikimedia.com/blog/parsed-wikipedia-tables/ Parsed Tables]. The new Parsed Tables feature extracts and represents Wikipedia tables in structured JSON. This improves machine accessibility as part of the [https://enterprise.wikimedia.com/api/structured-contents/ Structured Contents initiative]. Structured Contents output is freely available through the [https://enterprise.wikimedia.com/docs/on-demand/#article-structured-contents-beta On-demand API], or through Wikimedia Cloud Services. 
* A [https://www.kaggle.com/datasets/wikimedia-foundation/english-wikipedia-people-dataset dataset of English Wikipedia biographical information] from [[m:Special:MyLanguage/Wikimedia Enterprise|Wikimedia Enterprise]] has been published on Kaggle, for evaluation and research. This provides structured data from more than 1.5 million biographies, including birth and death dates, education, affiliations, careers, awards, and more (from a June 2024 snapshot).
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.19|MediaWiki]]

'''Meetings and events'''
* [[wmania:Special:MyLanguage/2026:Scholarships|Scholarship applications]] for Wikimania 2026 in Paris, France, are open until October 31.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/38|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W38&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 17:08, 15 September 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29263921 --&gt;

== Wikipedia translation of the week: 2025-39 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Federation of Central America (1921–1922)]]'''&lt;br /&gt; &lt;small&gt;''([[:es:Federación de Centro América (1921-1922)]])&amp;#32;([[:ar:اتحاد أمريكا الوسطى (1921-1922)]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Central America's Northern Triangle (orthographic projection).png|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Federation of Central America''' (Spanish: Federación de Centro América)[1] was a short-lived federal republic that existed in Central America between 1921 and 1922. The federation consisted of the Central American nations of El Salvador, Guatemala, and Honduras. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:45, 22 September 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29311347 --&gt;

== Tech News: 2025-39 ==

&lt;section begin=&quot;technews-2025-W39&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/39|Translations]] are available.

'''Weekly highlight'''
* [https://zonestamp.toolforge.org/1758726000 On September 24th at 15:00 UTC], all Wikimedia sites users will experience a brief read-only period due to a scheduled [[m:Special:MyLanguage/Tech/Server switch|datacenter server switchover]]. The Wikimedia Foundation's Site Reliability Engineering (SRE) team will redirect all traffic from one primary server to its backup. You can listen to the switchover using the [http://listen.hatnote.com/ &quot;Listen to Wikipedia&quot;] tool, where you will hear edits stop for a few minutes during the read-only phase, then resume. This twice-yearly datacenter server switchover ensures reliability by testing the backup datacenter, so that our sites can stay online even if the primary datacenter fails. You can [[diffblog:2025/03/12/hear-that-the-wikis-go-silent-twice-a-year/|read more about the process on the Diff blog]].

'''Updates for editors'''
* Editors of [[f:Special:Mylanguage/Wikifunctions:Status updates/2025-09-12#Next round of Wiktionaries to receive embedded Wikifunctions calls|60 more Wiktionaries]] will soon be able to call [[f:Special:MyLanguage/Wikifunctions:Introduction|functions from Wikifunctions]] and integrate them into their pages. A function takes one or more inputs and transforms them into a desired output, like adding numbers, converting miles to meters, calculating elapsed time, or declining a word into a case. They will join the other [[f:Special:MyLanguage/Wikifunctions:Status updates/2025-08-29#Wikifunctions available on 65 Wiktionaries|65 Wiktionary language editions]], which already have access to embedded Wikifunctions calls. Later this year, plans are in place to expand to more Wiktionaries and the Incubator.
* A new [[mw:Special:MyLanguage/Help:Magic words#Technical metadata of another page|parser function]] has been added: &lt;code&gt;&lt;nowiki&gt;{{#contentmodel}}&lt;/nowiki&gt;&lt;/code&gt;. Template editors and admins can use it to get the localized or canonical name of the [[mw:Special:MyLanguage/Help:ChangeContentModel|content model]] of a specific page. The function makes it easier to create and edit system messages, such as ''MediaWiki:editinginterface'', even when you switch types of pages, like wiki, JavaScript, CSS or JSON page. [https://phabricator.wikimedia.org/T328254]
* Adding or editing a &lt;code&gt;DISPLAYTITLE&lt;/code&gt; for an article using VisualEditor will no longer be broken. Editors who use VisualEditor mode to modify the &lt;code&gt;&lt;nowiki&gt;{{DISPLAYTITLE}}&lt;/nowiki&gt;&lt;/code&gt; would no longer have the literal text &quot;DISPLAYTITLE&quot; or its localized variant added to their articles. A list of pages that may have been affected and might need cleanup is documented in [[phab:P83438|this ticket]]. 
* Beta users of the Wikipedia Android app can now try the redesigned [[mw:Special:MyLanguage/Wikimedia Apps/Team/Android/Activity Tab Experiment|Activity tab]], which replaces the Edits tab. The new tab offers personalized insights into reading, editing, and donation activity, while simplifying navigation and making app use more engaging.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:12}} community-submitted {{PLURAL:12|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.20|MediaWiki]]

'''In depth'''
* Wikifunctions users can now import many essential facts involving [[f:Special:MyLanguage/Z6011|geo-coordinates]], [[f:Special:MyLanguage/Z6010|quantities]] and [[f:Special:MyLanguage/Z6064|time]] values from Wikidata. This is made possible by the creation of Wikifunctions types for these values, which makes them available for use by functions in Wikifunctions. Learn more about how this works in [[c:File:ImportingWikidataDatatypesIntoWikifunctions.webm|this video]] and Wikifunctions' [[f:Special:MyLanguage/Wikifunctions:Status updates/2025-08-01#News in Types I: Wikidata quantity|August 1 newsletter]] (for quantities) and [[f:Special:MyLanguage/Wikifunctions:Status updates/2025-08-22#News in Types: Wikidata geo-coordinate|August 22 newsletter]] (for geo-coordinates).

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/39|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W39&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 22:56, 22 September 2025 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29305556 --&gt;

== Wikipedia translation of the week: 2025-40 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Palazzo delle Poste (Latina)]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Postelittoria2.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
Il '''Palazzo delle Poste''', fino al 1945 Ricevitoria Postelegrafonica di Littoria, è un edificio postale di Latina, situato in piazzale dei Bonificatori.

Costruito nel 1932 in stile razionalista con influenze futuriste, riscontrabili nell'utilizzo di ampie superfici vetrate e di volumi verticali, oltre che per la presenza di l’utilizzo di materiali e scelte di design molto in voga all'epoca come, come i mattoni a vista, il travertino di Tivoli e l'Anticorodal (una lega di alluminio), ospita l'ufficio postale Latina Centro. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 00:58, 29 September 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29341788 --&gt;

== Tech News: 2025-40 ==

&lt;section begin=&quot;technews-2025-W40&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/40|Translations]] are available.

'''Weekly highlight'''
* A major software upgrade has been made to [[phab:|Phabricator]]. The update introduces performance improvements, a refreshed search interface, enhancements to Maniphest task search, updates to user profile pages and project workboards, new Herald automation features, as well as general text input, mobile experience improvements and more. [https://phabricator.wikimedia.org/phame/post/view/321/iterative_improvements_september_2025/]

'''Updates for editors'''
* The Community Tech team will release the new Community Wishlist extension on October 1, that will improve the way wishes will be submitted. The new extension will allow users to add tags to their wishes to better categorise them, and (in a future iteration) to filter them by status, tags and focus areas. It will also be possible to support individual wishes again, as requested by the community in many instances. The old system will be retired. There will be a brief period of downtime while the extension is deployed and wishes are migrated to the new system. You can read more about this [[:m:Special:MyLanguage/Community Wishlist/Updates|in the latest update]] or you can consult the [[:mw:Special:MyLanguage/Help:Extension:CommunityRequests|current documentation on MediaWiki]].
* As announced [[diffblog:2025/09/02/better-detecting-bots-and-replacing-our-captcha/|on Diff blog]], the production trial of the [[mw:Special:MyLanguage/Product Safety and Integrity/Anti-abuse signals/hCaptcha|hCaptcha]] service for bot detection has begun. The trial is currently using hCaptcha to protect account creation on Chinese, Persian, Portuguese, Indonesian, Japanese, and Turkish Wikipedias, where it will replace our existing [[mw:Special:MyLanguage/Extension:ConfirmEdit#FancyCaptcha|CAPTCHA]] (FancyCaptcha). The goal with the trial is to better block bots while also improving usability and accessibility for users who encounter CAPTCHA challenges.
* The [[mw:Special:MyLanguage/Extension:CampaignEvents|CampaignEvents]] extension has been [[m:Special:MyLanguage/CampaignEvents/Deployment status|deployed]] to Wikimedia Commons. The extension makes it easier to organize and participate in collaborative activities, like edit-a-thons and WikiProjects, on the wikis. On Commons, anyone who is a registered user can use it as an event participant. To use it as an organizer, someone needs to have the [[c:Special:MyLanguage/Commons:Event organizers|event organizer right]].
* [[:m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing|Sub-referencing]], a new feature to re-use references with different details has been released to German Wikipedia. You can [[:m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing#test|test the feature]] on testwiki or [https://en.wikipedia.beta.wmcloud.org/wiki/Sub-referencing on betawiki] as well. Please share your thoughts on [[:m:Talk:WMDE Technical Wishes/Sub-referencing#Templates used in sub-references|using templates in sub-references]] or [[:m:Talk:WMDE Technical Wishes/Sub-referencing#Pilot wikis|volunteer to become a pilot wiki]].
* On wikis using the [[mw:Special:MyLanguage/Help:Growth/Mentorship|Mentorship]] system, communities can now opt experienced editors out of Mentorship through [[{{#special:CommunityConfiguration/Mentorship}}]]. Within this setting, communities may define thresholds, based on edit count and account age, to decide when an editor is considered experienced enough to no longer receive Mentorship. [https://phabricator.wikimedia.org/T403563]
* The Editing Team and the Machine Learning Team are working on a new check for newcomers: [[mw:Special:MyLanguage/Edit check/Tone Check|Tone check]]. Using a prediction model, this check will encourage editors to improve the tone of their edits, using artificial intelligence. We invite volunteers to review the first version of the Tone language model for the following languages: Arabic, Czech, German, Hebrew, Indonesian, Dutch, Polish, Russian, Turkish, Chinese, Farsi, Italian, Norwegian, Romanian and Latvian. Users from these wikis interested in reviewing this model are [[mw:Special:MyLanguage/Edit_check/Tone_Check/Model_evaluation|invited to sign up at MediaWiki.org]]. The deadline to sign up is on October 3, which will be the start date of the test.
* The rollout of [[:mw:Special:MyLanguage/Help:Manage blocks|multiblocks]] had the side effect that non-active block logs may have been shown on {{#special:Contributions}} and on blocked users' user and user_talk pages. This issue will be fully resolved in a few days. As part of the fix, [{{fullurl:Special:Allmessages|prefix=sp-contributions-blocked-notice}} messages prefixed with &lt;code&gt;sp-contributions-blocked-notice&lt;/code&gt;] will be removed and replaced with [{{fullurl:Special:Allmessages|prefix=blocked-notice-logextract}} those prefixed with &lt;code&gt;blocked-notice-logextract&lt;/code&gt;] in a few weeks. Please help translate the new messages and update any local overrides if needed.
* There was a bug with links added using visual editor if they included characters such as &lt;code dir=ltr&gt;&lt;nowiki&gt;[ ] |&lt;/nowiki&gt;&lt;/code&gt; after the fragment identifier (&lt;code&gt;&lt;nowiki&gt;#&lt;/nowiki&gt;&lt;/code&gt;). They were not encoded properly creating an incorrect link. This has been fixed. [https://phabricator.wikimedia.org/T404823]
* One new wiki has been created: a {{int:project-localized-name-group-wikiquote/en}} in [[d:Q9237|Malay]] ([[q:ms:|&lt;code&gt;q:ms:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T404698]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:21}} community-submitted {{PLURAL:21|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the [[mw:Special:MyLanguage/Product Safety and Integrity/Anti-abuse signals/User Info|User Info Card]] now displays currently active global lock/blocks. [https://phabricator.wikimedia.org/T401128]

'''Updates for technical contributors'''
* Later this week, editors using Lua modules will be able to use the &lt;code&gt;[[mw:Special:MyLanguage/Extension:Scribunto/Lua reference manual#mw.title.newBatch|mw.title.newBatch]]&lt;/code&gt; function to look up the existence of up to 25 pages at once, in a way that only increases the [[mw:Special:MyLanguage/Manual:Parser functions#Expensive parser functions|expensive function]] count once.
* A new [[m:Special:MyLanguage/Product and Technology Advisory Council/Unsupported Tools Working Group|Unsupported Tools Working Group]] has been formed as part of ongoing efforts to collectively determine technical work priorities, similar to the [[m:Special:MyLanguage/Product and Technology Advisory Council|Product &amp; Technology Advisory Council]] (PTAC). The working group will help prioritize and review requests for support of unmaintained extensions, gadgets, bots, and tools. For the first cycle, the group will be prioritizing an unsupported Wikimedia Commons tool.
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.21|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/40|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W40&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:54, 29 September 2025 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29355230 --&gt;

== Wikipedia translation of the week: 2025-41 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Majed Abu Maraheel]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Majed Abu Maraheel''' was a Palestinian long-distance runner, football player, security officer, and athletics coach, who was the first Palestinian to compete at the Olympic Games. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 12:48, 6 October 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29341788 --&gt;

== Tech News: 2025-41 ==

&lt;section begin=&quot;technews-2025-W41&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/41|Translations]] are available.

'''Weekly highlight'''
* [[mw:Special:MyLanguage/Help:Edit check#paste|Paste Check]] is a new Edit Check feature to help avoid and fight copyright violations. When editors paste text into an article, Paste Check prompts them to confirm the origin and licensing of the content. Starting Wednesday, 8 October, [[phab:T403680|22 wikis will test Paste Check]]. Paste Check will help new volunteers understand and follow the policies and guidelines necessary to make constructive contributions to Wikipedia projects.
'''Updates for editors'''
* Mobile devices will receive mobile articles directly on the standard domain (like &lt;code&gt;en.wikipedia.org&lt;/code&gt;), instead of via a redirect to an &quot;m&quot; domain (like &lt;code&gt;en.m.wikipedia.org&lt;/code&gt;). This change improves performance. This week it will be enabled on Wikipedias. The existing mobile URLs and the &quot;Desktop view&quot; opt-out remain available. [[mw:Requests for comment/Mobile domain sunsetting/2025 Announcement|Learn more]]. [https://phabricator.wikimedia.org/T214998]
* New [[mw:Special:MyLanguage/Help:CirrusSearch#creationdate and lasteditdate|date filters]], &lt;code dir=ltr&gt;creationdate:&lt;/code&gt; and &lt;code dir=ltr&gt;lasteditdate:&lt;/code&gt;, are now available in the wiki search engine. This allows users to filter search results by a page's first or last revision date. The filters support comparison operators (e.g. &lt;code dir=ltr&gt;&gt;2024&lt;/code&gt;) and relative dates (e.g. &lt;code dir=ltr&gt;today-1d&lt;/code&gt;), making it easier to find recently updated content or pages within specific age ranges. [https://phabricator.wikimedia.org/T403593]
* [[f:|Wikifunctions]] now supports rich text in embedded calls across the 150 wikis where it's enabled. To showcase this, the team created a [[f:Z26333|Latin declination table]] that Wiktionary editors can use to automatically generate noun forms, producing clear, formatted results — see an [[f:Wikifunctions:Embedded function calls/Wiktionary tables demonstration|example output]]. If you need any help or have any feedback, please [[f:Wikifunctions:Project chat|contact the Wikifunctions Team]]. [https://phabricator.wikimedia.org/T397402]
* An edit link will now appear inside the categories box on article pages for logged in users, which will directly launch the VisualEditor category dialog. [https://phabricator.wikimedia.org/T291691]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:34}} community-submitted {{PLURAL:34|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, there was a problem downloading pdf files last week and that has been resolved. [https://phabricator.wikimedia.org/T405957]
'''Updates for technical contributors'''
* The field &lt;code dir=ltr&gt;rev_sha1&lt;/code&gt; in the revision database table is being removed in favor of &lt;code dir=ltr&gt;content_sha1&lt;/code&gt; in the content database table. See [https://lists.wikimedia.org/hyperkitty/list/cloud@lists.wikimedia.org/thread/2D2M3SP4WHR6BXXKTZ2PBLZQYR3EGQVR/ the announcement] for more information.
* The [[mw:Special:MyLanguage/Reading/Web|Reader Experience team]] will roll out [[w:en:Light-on-dark color scheme|Dark Mode]] user interface on all Wikimedia sites on October 29, 2025. All anonymous users of Wikimedia sites will have the option to activate a color scheme that features light-colored text on a dark background. This is designed to provide a more comfortable reading experience, especially in low-light situations. Template authors and technical contributors are encouraged to [[mw:Special:MyLanguage/Reading/Web/Accessibility for reading/Updates/2024-04|learn how to make pages ready for Dark mode]] and address any compatibility issues found in templates in their wiki before the enablement. Please contact the Web team for questions or any support on [[mw:Talk:Reading/Web/Accessibility for reading#|this talk page]] before the enablement. [https://phabricator.wikimedia.org/T395628]
* Starting on Monday, October 6, API endpoints under the &lt;code&gt;rest.php&lt;/code&gt; path will be rerouted through a new internal API Gateway. Individual wikis will be updated based on the standard release groups, with total traffic increased over time. This change is expected to be non-breaking and non-disruptive. If any issues are observed, please file a Phabricator ticket to the [[phab:tag/serviceops/|Service Ops team board]]. [https://phabricator.wikimedia.org/T400130]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.22|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/41|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W41&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 17:24, 6 October 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29400897 --&gt;

== Wikipedia translation of the week: 2025-42 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Abortion in Eritrea]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
In Eritrea, abortion is banned except on the grounds of pregnancy from rape or incest, pregnancy of a minor, or risk to physical or mental health. Legal abortions require medical or judicial approval. Prior to Eritrea's independence, it applied Ethiopia's abortion law of the 1950s, which banned abortion unless life-saving. After independence, the 1991 penal code adapted this law to lift punishments on abortions on the grounds of rape, incest, or risk to life or health, but legal abortions did not exist in effect. The penal codes of 2001 and 2015 required physicians to prove health grounds for abortion. Unsafe abortion is common and contributes to maternal mortality in Eritrea. Post-abortion care is unavailable in some regions. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:06, 13 October 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29341788 --&gt;

== Tech News: 2025-42 ==

&lt;section begin=&quot;technews-2025-W42&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/42|Translations]] are available.

'''Weekly highlight'''
* Last week, improvements to account security and two-factor authentication (2FA) features were enabled across all wikis. These changes include user interface improvements for [https://auth.wikimedia.org/metawiki/wiki/Special:AccountSecurity Special:AccountSecurity], the support of multiple 2FA methods via authenticator apps and portable security keys (previously users could only enable one method), and a new Recovery Codes module which facilitates fewer account lockouts due to lost two-factor apps and devices. As part of the [[mw:Special:MyLanguage/Product Safety and Integrity/Account Security|Account Security]] project, work is continuing through the rest of 2025 on further user experience improvements, and support for passkeys as an alternate second factor. 

'''Updates for editors'''

* Another part of the Account security project is making 2FA generally available to all users. Along with editors with advanced privileges, such as administrators and bureaucrats, 40% of editors now have access to 2FA. You can check if you have access at [https://auth.wikimedia.org/metawiki/wiki/Special:AccountSecurity Special:AccountSecurity]. Instructions for activation are on the linked page. The plan is to continue increasing availability if it is determined that the user support capabilities are able to support global usage. [https://phabricator.wikimedia.org/T400579]
* This week, users at wikis where talk page [[mw:Special:MyLanguage/Talk pages project/Usability|Usability Improvements]] are already available by default (everywhere ''except'' the 12 wikis listed in [[phab:T379264|T379264]]) will gain the ability to Thank a comment directly from the talk page it appears on. Before this change, Thanking could only be done by visiting the revision history of the talk page. You can [[diffblog:2025/10/13/revolutionizing-gratitude-a-new-era-of-thanking-comments/|learn more about this change]]. [https://phabricator.wikimedia.org/T366095]
* Users who have not [[Special:Preferences#mw-prefsection-personal-email|verified their email address]] will soon be receiving monthly Notification reminders to do so. This is because users who have verified their email can more easily recover their account. These reminders will not be sent if the user is inactive or removes the unverified email from their account. [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Email_confirmation][https://phabricator.wikimedia.org/T58074]
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:21}} community-submitted {{PLURAL:21|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a fix was made for an occasional error with saving translated paragraphs in the Content Translation tool, and the related error messages are now easier to see. [https://phabricator.wikimedia.org/T376531]

'''Updates for technical contributors'''

* The Unsupported Tools Working Group has chosen [[c:Special:MyLanguage/Commons:Video2commons|Video2Commons]] as the first tool for its pilot cycle. The group will explore ways to improve and sustain the tool over the coming months. [[m:Special:MyLanguage/Product and Technology Advisory Council/Unsupported Tools Working Group|Learn more on Meta]].
* [[File:Octicons-sync.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.23|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/42|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W42&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:00, 13 October 2025 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29434481 --&gt;

== Wikipedia translation of the week: 2025-43 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Liberation of Auschwitz concentration camp]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Auschwitz Liberated January 1945.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
On 27 January 1945, Auschwitz—a Nazi concentration camp and extermination camp in occupied Poland where more than a million people were murdered as part of the Nazis' &quot;Final Solution&quot; to the Jewish question—was liberated by the Soviet Red Army during the Vistula–Oder Offensive. Although most of the prisoners had been forced onto a death march, about 7,000 had been left behind. The Soviet soldiers attempted to help the survivors and were shocked at the scale of Nazi crimes. The date is recognized as International Holocaust Remembrance Day. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:04, 20 October 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29452019 --&gt;

== Tech News: 2025-43 ==

&lt;section begin=&quot;technews-2025-W43&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/43|Translations]] are available.

'''Updates for editors'''
* To optimize how user data is stored in our databases, the saved preferences of users who haven't logged in for over five years and have fewer than 100 edits will be cleared. When those users return, default settings will apply. [https://phabricator.wikimedia.org/T406724]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:20}} community-submitted {{PLURAL:20|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, there was a broken link from the GlobalContributions interface message to the XTools GlobalContributions page which has now been fixed. [https://phabricator.wikimedia.org/T406415]

'''Updates for technical contributors'''
* The work to reroute all traffic to API endpoints under the &lt;code dir=ltr&gt;&lt;nowiki&gt;rest.php&lt;/nowiki&gt;&lt;/code&gt; route through a common API gateway is now complete. If any issues are observed, please file a phabricator ticket to the [[phab:tag/serviceops/|Service Ops team board]].
* Edits to Wikidata references or qualifiers will now be shown in RecentChanges and Watchlist entries on other wikis less often, reducing unnecessary notifications. This will reduce the overall quantity of 'noisy' entries. Wikidata's own pages remain unchanged. [https://phabricator.wikimedia.org/T401290]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.24|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/43|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W43&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:37, 20 October 2025 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29478670 --&gt;

== Wikipedia translation of the week: 2025-44 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Black Diaries]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Black Diaries''' are diaries purported to have been written by the Irish revolutionary Roger Casement, which contained accounts of homosexual liaisons with young men. They cover the years 1903, 1910 and 1911 (two) and were handed in to Scotland Yard after his capture in April 1916. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:51, 27 October 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29487357 --&gt;

== Tech News: 2025-44 ==

&lt;section begin=&quot;technews-2025-W44&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/44|Translations]] are available.

'''Updates for editors'''
* The Wikipedia iOS app has launched an A/B/C test of improvements made to the tabbed browsing feature for select regions and languages. The test, named “More dynamic tabs”, explores new tab experiences and includes “Did you know” and “Because you read” article recommendations. You can [[mw:Special:MyLanguage/Wikimedia Apps/Team/iOS/Tabbed Browsing (Tabs)/New Tab Experience and Recommendations Experiment|read more on the project page]].
* Autoconfirmed users on [[gitiles:operations/mediawiki-config/+/a2d2aaab9ace84280dd2f4c70a33bb69cd73850f/dblists/small.dblist|small]] and [[gitiles:operations/mediawiki-config/+/a2d2aaab9ace84280dd2f4c70a33bb69cd73850f/dblists/medium.dblist|medium wikis]] with the CampaignEvents extension can now use [[m:Special:MyLanguage/Event Center/Registration|Event Registration]] without the Event Organizer right. This feature lets organizers enable registration, manage participants, and lets users register with one click instead of signing event pages.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:31}} community-submitted {{PLURAL:31|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the issue of flashing colors when holding or pressing the arrow keys under the dark mode settings in Vector 2022 has been fixed. [https://phabricator.wikimedia.org/T402285]

'''Updates for technical contributors'''

* The CampaignEvents extension will be deployed to all remaining wikis during the week of 17 November 2025. The extension currently includes three features: Event Registration, Collaboration List, and Invitation List. For this rollout, Invitation List will not be enabled on Wikifunctions and MediaWiki unless requested by those communities. [[m:Special:MyLanguage/CampaignEvents/Deployment status|Visit the deployment page to learn more]].
* The SwaggerUI-based REST sandbox experience is now live on all wiki projects. The sandbox can be accessed through the [[{{#special:RestSandbox}}]] page. Please report any issues to the MediaWiki Interfaces team board, or join the discussion on the [[mw:Special:MyLanguage/MediaWiki Interfaces Team/Feature Feedback/REST Sandbox|project launch]] page. [https://phabricator.wikimedia.org/project/board/6931/]
* Transform endpoints with a trailing slash path in the MediaWiki REST API are now marked as deprecated. They will remain functional during this time, but removal is expected by the end of January 2026. All API users currently calling them are encouraged to transition to the non-trailing slash versions. Both endpoint variations can be found and tested using the [https://test.wikipedia.org/w/index.php?api=mw-extra&amp;title=Special%3ARestSandbox REST Sandbox]. See the [[mw:API/Deprecation|MediaWiki REST API Deprecation]] page for more detailed information about the API deprecation policies and procedures.
* A dedicated [[mw:API:REST API/Changelog|changelog now exists for the MediaWiki REST API]]. The changelog provides an overview of these changes, making it easier for developers to keep track of improvements and iterations. Announcements will also continue to flow through the standard communication channels, including Tech News and email distribution lists, but can now be more easily referenced from a central location. If you have feedback about the style, structure, or content of this changelog, please [[mw:API talk:REST API/Changelog|join the discussion]].
* Administrators can delete the tracking category which was previously added by the JsonConfig extension, as it is no longer used. See the categories linked from [[d:Q130635582#sitelinks-wikipedia|Q130635582]]. It is OK if there are still pages listed in the category as that is just a caching issue, and they will be automatically cleared out the next time each page is edited. [https://phabricator.wikimedia.org/T378352]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.25|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/44|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W44&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:32, 27 October 2025 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29513638 --&gt;
|}

== Wikipedia translation of the week: 2025-45 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Consolations (Liszt)]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Franz Liszt - Consolation No. 3, Lento placido.ogg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Consolations''', S. 171a/172 (German: Tröstungen) are a set of six solo piano works by Franz Liszt. The compositions take the musical style of nocturnes with each having its own distinctive style. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:52, 3 November 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29558323 --&gt;

== Tech News: 2025-45 ==

&lt;section begin=&quot;technews-2025-W45&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/45|Translations]] are available.

'''Updates for editors'''
* Administrators will now find that [[{{#special:MergeHistory}}]] is now significantly more flexible about what it can merge. It can now merge sections taken from the middle of the history of the source (rather than only the start) and insert revisions anywhere in the history of the destination page (rather than only the start). [https://phabricator.wikimedia.org/T382958]
* For users with &quot;{{int:discussiontools-preference-autotopicsub}}&quot; [[Special:Preferences#mw-prefsection-editing|enabled in their preferences]], starting a new topic or adding a reply to an existing topic will now subscribe them to replies to that topic. Previously, this would only happen if the DiscussionTools &quot;{{int:Skin-action-addsection}}&quot; or &quot;{{int:Discussiontools-replybutton}}&quot; widgets were used. When DiscussionTools was originally launched existing accounts were not opted in to automatic topic subscriptions, so this change should primarily affect newer accounts and users who have deliberately changed their preferences since that time. [https://phabricator.wikimedia.org/T290778]
* Scribunto modules can now be used to [[mw:Special:MyLanguage/Extension:Scribunto/Lua reference manual#SVG library|generate SVG images]]. This can be used to build charts, graphics and other visualizations dynamically through Lua, reducing the need to compose them externally and upload them as files. [https://phabricator.wikimedia.org/T405861]
* Wikimedia sites now provide all anonymous users with the option to enable a dark mode color scheme, featuring light-colored text on a dark background. This enhancement aims to deliver a more enjoyable reading experience, especially in dimly lit environments.  [https://phabricator.wikimedia.org/T395628]
* Users with large watchlists have long faced timeouts when editing [[Special:EditWatchlist|Special:EditWatchlist]]. The page now loads entries in smaller sections instead of all at once due to a paging update, allowing everyone to edit their watchlists smoothly. As part of the database update, sorting by expiry has been removed because it was over 100× slower than sorting by title. A [https://meta.wikimedia.org/wiki/Community_Wishlist/W454 community wish] has been created to explore alternative ways to restore sort-by-expiry. If this feature is important to you, please support the wish! [https://phabricator.wikimedia.org/T41510]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:31}} community-submitted {{PLURAL:31|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the fixing of the persisting highlighting when using VisualEditor find and replace during a query. [https://phabricator.wikimedia.org/T407318]
'''Updates for technical contributors'''
* Since 2019 the [[m:Special:MyLanguage/Wikimedia URL Shortener|Wikimedia URL Shortener]] at https://w.wiki is available for all Wikimedia wikis to create short links to articles, permalinks, diffs, etc. It is available in the sidebar as &quot;Get shortened URL&quot;. There are 30 wikis that also install an older &quot;ShortUrl&quot; extension. The old extension will soon be removed. This means &lt;code&gt;/s/&lt;/code&gt; URLs will not be advertised under article titles via HTML &lt;code dir=ltr&gt;class=&quot;title-shortlink&quot;&lt;/code&gt;. The &lt;code&gt;/s/&lt;/code&gt; URLs will keep working. [https://phabricator.wikimedia.org/T107188]
* On Thursday, October 30, the [[:mw:Special:MyLanguage/MediaWiki Interfaces Team|MediaWiki Interfaces]] and [[:mw:Special:MyLanguage/Wikimedia Site Reliability Engineering|SRE Service Operations]] teams began rerouting Action API traffic through a common API gateway. Individual wikis will be updated based on the standard release groups, with total traffic increased over time. This change is expected to be non-breaking and non-disruptive. If any issues are observed, please file a Phabricator ticket to the [https://phabricator.wikimedia.org/tag/serviceops/ Service Ops team] board.
* MediaWiki Train deployments will pause for the final two weeks of 2025: 22 December and 29 December. Backport windows will also pause between Monday, 22 December 2025 and Thursday, 2 January 2026. A backport window is a scheduled time to add things like bug fixes and configuration changes. There are seven deployment trains remaining for 2025. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/SMWTEAES4SDLDUSK4HMWNBSKNCXZAWYN/]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.45/wmf.26|MediaWiki]]

'''In depth'''
* In 2025, the Wikimedia Foundation reported that AI systems and search engines increasingly use Wikipedia content without driving users to the site, contributing to an 8% drop in human pageviews compared to 2024. After detecting bots disguised as humans, Wikimedia updated its traffic data to reflect this shift. Read more about current user trends on Wikipedia in [[diffblog:2025/10/17/new-user-trends-on-wikipedia/|a Diff blog post]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/45|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W45&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:35, 3 November 2025 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29552512 --&gt;

== Wikipedia translation of the week: 2025-46 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Marine coastal ecosystem]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Vegetation and fauna processes controlling benthic biogeochemical fluxes.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
A '''marine coastal ecosystem''' is a marine ecosystem which occurs where the land meets the ocean. Worldwide there is about 620,000 kilometres (390,000 mi) of coastline. Coastal habitats extend to the margins of the continental shelves, occupying about 7 percent of the ocean surface area. Marine coastal ecosystems include many very different types of marine habitats, each with their own characteristics and species composition. They are characterized by high levels of biodiversity and productivity.

For example, estuaries are areas where freshwater rivers meet the saltwater of the ocean, creating an environment that is home to a wide variety of species, including fish, shellfish, and birds. Salt marshes are coastal wetlands which thrive on low-energy shorelines in temperate and high-latitude areas, populated with salt-tolerant plants such as cordgrass and marsh elder that provide important nursery areas for many species of fish and shellfish. Mangrove forests survive in the intertidal zones of tropical or subtropical coasts, populated by salt-tolerant trees that protect habitat for many marine species, including crabs, shrimp, and fish. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:54, 10 November 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29584005 --&gt;

== Tech News: 2025-46 ==

&lt;section begin=&quot;technews-2025-W46&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/46|Translations]] are available.

'''Updates for editors'''
[[File:Talk pages default look (April 2023).jpg|thumb|alt=Screenshot of the visual improvements made on talk pages|Example of a talk page with the new design, in French.]]
* Starting November 12, users will see a change in the [[m:Special:MyLanguage/Talk pages project/Feature summary#Usability improvements|appearance of talk pages]] on [[Phab:T379264|some Wikipedias]]. Almost [[phab:T392121|all wikis]] have received this design change; [[phab:T409297|English Wikipedia]] will get these changes later. You can read more [[diffblog:2024/05/02/making-talk-pages-better-for-everyone/|on ''Diff'']]. Users can opt out of these changes [[Special:Preferences#mw-prefsection-editing|in their user preferences]] in &quot;{{int:discussiontools-preference-visualenhancements}}&quot;. [https://phabricator.wikimedia.org/T379264]
* MediaWiki can now display a [[mw:Special:MyLanguage/Help:Protection indicators|page indicator]] automatically while a page is protected. This feature is disabled by default. It can be enabled by [[m:Special:MyLanguage/Requesting wiki configuration changes|community request]]. [https://phabricator.wikimedia.org/T12347]
* Using the &quot;{{int:showpreview}}&quot; or &quot;{{int:showdiff}}&quot; buttons in the wikitext editor will now carry over certain URL parameters like '[[mw:Special:MyLanguage/Manual:Parameters to index.php#useskin|useskin]]', '[[mw:Special:MyLanguage/Manual:Parameters to index.php#uselang|uselang]]' and '[[mw:Special:MyLanguage/Help:Section#Editing sections|section]]'. This update also fixes an issue where, if the browser crashed while previewing an edit to a single section, saving this edit could overwrite the entire page with just that section’s content. [https://phabricator.wikimedia.org/T62744][https://phabricator.wikimedia.org/T24029][https://phabricator.wikimedia.org/T155097]
* Wikivoyage wikis can use [[mw:Special:MyLanguage/Help:Extension:Kartographer#Markers and counters|colored map markers in the article text]]. The text of these markers will now be shown in contrasting black or white color, instead of always being white. Local workarounds for the problem can be removed. [https://phabricator.wikimedia.org/T369454]
* The Activity tab in the Wikipedia Android app is now available for all users. The new tab offers personalized insights into reading, editing, and donation activity, while simplifying navigation and making app use more engaging. [https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Activity_Tab_Experiment]
* The Reader Growth team is launching an experiment called &quot;Image browsing&quot; to test how to make it easier for readers to browse and discover images on Wikipedia articles. This experiment, a mobile-only A/B test, will go live on English Wikipedia in the week of November 17 and will run for four weeks, affecting 0.05% of users on English wiki. The test launched on November 3 on Arabic, Chinese, French, Indonesian, and Vietnamese wikis, affecting up to 10% of users on those wikis. [https://www.mediawiki.org/wiki/Readers/Reader_Growth/WE3.1.3_Image_Browsing]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example the inability to lock accounts on mobile sites has been fixed. [https://phabricator.wikimedia.org/T256185]

'''Updates for technical contributors'''
* [[wikitech:Help talk:Toolforge/Toolforge standards committee#November 2025 committee nominations|Nominations are open on Wikitech]] for new [[wikitech:Help:Toolforge/Toolforge standards committee|Toolforge standards committee]] members. The committee oversees the Toolforge [[wikitech:Help:Toolforge/Right to fork policy|Right to fork policy]] and [[wikitech:Help:Toolforge/Abandoned tool policy|Abandoned tool policy]] among other duties. Nominations will remain open through 2025-11-28.
* The [[w:JSON Web Token#Standard fields|JWT issuer field]] in [[mw:Special:MyLanguage/OAuth/For Developers#OAuth 2|OAuth 2 access tokens]] for [[m:Special:MyLanguage/Help:Unified login|SUL wikis]] has been changed to &lt;code&gt;&lt;nowiki&gt;https://meta.wikimedia.org&lt;/nowiki&gt;&lt;/code&gt;. Old access tokens will still work. [https://phabricator.wikimedia.org/T399199]
* The [[w:JSON Web Token#Standard fields|JWT subject field]] in [[mw:Special:MyLanguage/OAuth/For Developers#OAuth 2|OAuth 2 access tokens]] will soon change from &lt;code&gt;&lt;user id&gt;&lt;/code&gt; to &lt;code dir=ltr style=&quot;white-space:nowrap&quot;&gt;mw:&lt;identity type&gt;:&lt;user id&gt;&lt;/code&gt;, where &lt;code&gt;&lt;identity type&gt;&lt;/code&gt; is typically &lt;code dir=ltr&gt;CentralAuth:&lt;/code&gt;&lt;!-- not a typo --&gt; (for [[m:Special:MyLanguage/Help:Unified login|SUL wikis]]) or &lt;code dir=ltr style=&quot;white-space:nowrap&quot;&gt;local:&lt;wiki id&gt;&lt;/code&gt; (for other wikis). This is to avoid conflicts between different user ID types, and to make OAuth 2 access tokens and the &lt;code&gt;sessionJwt&lt;/code&gt; cookie more similar. Old access tokens will still work. [https://phabricator.wikimedia.org/T399199]
* MediaWiki's block messages ([[MediaWiki:Blockedtext|blockedtext]], [[MediaWiki:Blockedtext-partial|blockedtext-partial]], [[MediaWiki:Autoblockedtext|autoblockedtext]], [[MediaWiki:Systemblockedtext|systemblockedtext]], [[MediaWiki:Blockedtext-tempuser|blockedtext-tempuser]], [[MediaWiki:Autoblockedtext-tempuser|autoblockedtext-tempuser]]) now support additional parameters indicating whether the user is blocked from editing their own user talk page &lt;code&gt;&lt;nowiki&gt;$9&lt;/nowiki&gt;&lt;/code&gt; or emailing other users &lt;code&gt;&lt;nowiki&gt;$&lt;/nowiki&gt;&lt;nowiki&gt;10&lt;/nowiki&gt;&lt;/code&gt;. [https://phabricator.wikimedia.org/T285612]
* A &lt;code&gt;REL1_45&lt;/code&gt; branch for MediaWiki core and each of the extensions and skins in Wikimedia git has been created. This is the first step in the release process for MediaWiki 1.45.0, scheduled for late November 2025. If you are working on a critical bug fix or working on a new feature, you may need to take note of this change. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/ZUY7TY3Z6XPZWZVAZV63OPO5OW52Q6GE/]
* The process for generating CirrusSearch dumps has been updated due to slowing performance. If you encounter any issues migrating to the replacement dumps, please contact the Search Platform Team for support. [https://phabricator.wikimedia.org/T366248][https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/3KQPOR6ACVN6OVLMLZPIBXQSWQKW4E3K/]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.2|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/46|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W46&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:38, 10 November 2025 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29606150 --&gt;

== Wikipedia translation of the week: 2025-47 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Elephant communication]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Three elephant's curly kisses.jpg|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Elephants communicate''' via touching, visual displays, vocalisations, seismic vibrations, and semiochemicals. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:24, 17 November 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29627457 --&gt;

== Tech News: 2025-47 ==

&lt;section begin=&quot;technews-2025-W47&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/47|Translations]] are available.

'''Updates for editors'''
* The [[mw:Special:MyLanguage/Readers/Reader Experience|Reader Experience team]] is experimenting with [[mw:Special:MyLanguage/Readers/Reader Experience/WE3.3.4_Reading lists|reading lists on mobile web]], allowing logged-in readers with no edits to save private lists of articles for later. The experiment is running on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias since the week of 10 November, and will begin on English Wikipedia the week of 17 November.
* Users who can’t receive their email verification code during login can now get help by submitting a form on a new special page. This update is part of the [[mw:Special:MyLanguage/Product Safety and Integrity/Account Security|Account Security]] initiative. If your account has an email address, please make sure you still have access to it. When logging in from a new device or location without 2FA, you may be asked to enter a 6-digit code sent by email to finish logging in. [[mw:Special:MyLanguage/Product Safety and Integrity/Account Security#Why are you requiring me to enter a code from my email to log in? Can I opt out of this?|Learn more]].
* One new wiki has been created: a {{int:project-localized-name-group-wikisource}} in [[d:Q13324|Minangkabau]] ([[s:min:|&lt;code&gt;s:min:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T408317]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:23}} community-submitted {{PLURAL:23|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* As part of the [[mw:Special:MyLanguage/Parsoid/Parser Unification|Parser Unification]] project, the Content Transform Team rolled out Parsoid as the default parser to many low-traffic Wikipedias and is preparing the next step to high traffic ones. This message is an invitation for you to opt-in to Parsoid, as described in the [[mw:Special:MyLanguage/Help:Extension:ParserMigration|Extension:ParserMigration]] documentation, and identify any issues you might encounter with your own workflow using bots, gadgets, or user scripts. Please, let us know through the ''&quot;Report Visual Bug&quot;'' link in the Tools sidebar or create a phab ticket and tag the [[phab:project/view/5846|Content Transform Team in Phabricator]].
* Unsupported Tools: Several issues with [[:c:Special:MyLanguage/Commons:Video2commons|Video2Commons]] have been fixed, including filename-related upload failures, black-video imports, and retry handling. AV1 support has also been added. Ongoing work focuses on backend stability, ffmpeg errors, subtitle imports, metadata handling, and playlist uploads. To track specific tasks, check the [[phab:tag/video2commons/|Phabricator board]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.3|MediaWiki]]

'''Meetings and events'''
* Save the date for the next Wikimedia Hackathon happening in Milan, Italy from May 1–3, 2026. Registration will open in January 2026. [https://pretix.eu/wikimedia/Hackathon-2026/ Scholarship applications are currently open], and will close on November 28, 2025. If you have any questions, please email &lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;hackathon@wikimedia.org&lt;/bdi&gt;.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/47|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W47&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 17:27, 17 November 2025 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29627455 --&gt;

== Wikipedia translation of the week: 2025-48 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Animal-made art]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Painting Queen 1024x768.png|center|300px|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Animal-made art''' consists of works by non-human animals, that have been considered by humans to be artistic, including visual works, music, photography, and videography. Some of these are created naturally by animals, often as courtship displays, while others are created with human involvement.

There have been debates about the copyright status of these works, with the United States Copyright Office stating in 2014 that works that lack human authorship cannot have their copyright registered at the US Copyright Office. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:13, 24 November 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29627457 --&gt;

== Tech News: 2025-48 ==

&lt;section begin=&quot;technews-2025-W48&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/48|Translations]] are available.

'''Updates for editors'''
* Last week, the [[mw:Special:MyLanguage/Wikimedia Search Platform|Wikimedia Search Team]] recreated the &quot;DWIM&quot; (Do What I Mean) gadget functionality server-side, for Russian and Hebrew Wikipedias. This feature adds cross-keyboard suggestions to the standard search-box suggestions. For example, searching for ''&lt;span lang=&quot;und&quot; dir=&quot;ltr&quot;&gt;cxfcnmt&lt;/span&gt;'' on Russian Wikipedia will now add suggestions for ''&lt;span lang=&quot;ru&quot; dir=&quot;ltr&quot;&gt;счастье&lt;/span&gt;'' (&quot;happiness&quot;) that the user probably intended. They plan to enable this feature for other Russian and Hebrew wikis this week. [https://phabricator.wikimedia.org/T408734]
* Later this week, users of the &quot;{{int:codemirror-beta-feature-title}}&quot; [[Special:Preferences#mw-prefsection-betafeatures|beta feature]] will have syntax highlighting available in [[mw:Special:MyLanguage/Help:DiscussionTools|DiscussionTools]]. This requires that the &quot;{{int:discussiontools-preference-sourcemodetoolbar}}&quot; preference be set. [https://phabricator.wikimedia.org/T407918]
* [[mw:Special:MyLanguage/Help:Extension:CampaignEvents|Campaign events extension]] – the set of tools for coordinating events and other on-wiki collaborations has now been deployed to all Wikimedia wikis. A new feature known as [[m:Special:MyLanguage/CampaignEvents/Collaborative contributions|Collaborative contribution]] to help organizers and participants see the impact of activities has also been added. Join the upcoming [[m:Special:MyLanguage/Event:Connection learning session 3|learning session]] to see the new feature in action and share your feedback.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:24}} community-submitted {{PLURAL:24|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the bug which stopped CodeReviewBot from working, has now been fixed. [https://phabricator.wikimedia.org/T410417]

'''Updates for technical contributors'''
*  Users of Wikimedia API can join a usability study to help validate the new design of Wikimedia REST API sandboxes. Interested participants should fill the [https://wikimediafoundation.limesurvey.net/487662 recruitment survey]. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/IREJRRWTZTGCYWQHDMSNJFTQAEPOOAE3/]
* The MediaWiki Interfaces team is deprecating XSLT stylesheets within the Action API. Support for &lt;code dir=ltr&gt;format=xml'''&amp;xlst={stylesheet}'''&lt;/code&gt; will be removed from Wikimedia projects by the end of November, 2025. In addition, it will soon be disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44, and v1.45. Support for XSLT stylesheets will be fully removed from MediaWiki v1.46 (expected to release between April and May 2026). [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/5AX7UWAVVUNUSBOIRHMNOKWOZ5EZI3JX/]
* The WDQS legacy endpoint ([https://query-legacy-full.wikidata.org/ query-legacy-full.wikidata.org]) will be decommissioned at the end of December 2025, and finally closed down on 7th January 2026. After this date, users should expect requests to query.wikidata.org that require the full graph to fail or return invalid results if they are not rewritten to use SPARQL federation. The team encourages users to ensure that tools and workflows use the supported WDQS endpoints (&lt;span dir=ltr&gt;&lt;nowiki&gt;https://query.wikidata.org/&lt;/nowiki&gt;&lt;/span&gt; - Main graph or &lt;span dir=ltr&gt;&lt;nowiki&gt;https://query-scholarly.wikidata.org/&lt;/nowiki&gt;&lt;/span&gt; - Scholarly graph). For support with migrating use cases, please review the [[d:Special:MyLanguage/Wikidata:Data_access|Data Access]] and [[d:Wikidata:Request_a_query|Request a Query]] pages for details and assistance on alternative access methods.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.4|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/48|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W48&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 15:57, 24 November 2025 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29702226 --&gt;

== Wikipedia translation of the week: 2025-49 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Halachic state]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The term &quot;'''halachic state'''&quot; (Hebrew: מְדִינַת הֲלָכָה‎ Medīnat Hălāḵā) refers to a sovereign state that endorses Judaism in an official capacity and governs by Jewish religious law. It has been a subject of discussion among Orthodox Jews, particularly with regard to modern Israel, which, although a Jewish state, is not classified as a theocracy. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 08:01, 1 December 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29719355 --&gt;

== Tech News: 2025-49 ==

&lt;section begin=&quot;technews-2025-W49&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/49|Translations]] are available.

'''Updates for editors'''
* The Wikipedia Year in Review 2025 will be available on December 2 for users of iOS and Android Wikipedia apps, featuring new personalized insights, updated reading highlights, and refreshed designs. Learn more on the review's [[mw:Special:MyLanguage/Wikimedia Apps/Team/Wikipedia Year in Review/Updates|project page]].
* The Growth team is working on improving the text and presentation of the Verification Email sent to new users to make them more welcoming, useful and informative. Some new text have been drafted for A/B testing and you can help by translating them. See [[phab:T396155|Phabricator]].
* [[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]] will now be deployed at Japanese, Urdu and Chinese Wikipedias on December 2. Add a link is based on a prediction model that suggests links to be added to articles. While this feature has already been available on most Wikipedias, the prediction model could not support certain languages. A new model has now been developed to handle these languages, and it will be gradually rolled out to other Wikipedias over time. If you would like to know more, please contact [[mw:user:Trizek (WMF)|Trizek (WMF)]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:34}} community-submitted {{PLURAL:34|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the issue where search boxes on some Commons pages showed no results due to switch from SpecialSearch to MediaSearch, has now been fixed. [https://phabricator.wikimedia.org/T399476]
* Two new wikis have been created:
** a {{int:project-localized-name-group-wikipedia}} in [[d:Q36846|Toki Pona]] ([[w:tok:|&lt;code&gt;w:tok:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T404457]
** a {{int:project-localized-name-group-wikiquote}} in [[d:Q33655|Nigerian Pidgin]] ([[q:pcm:|&lt;code&gt;q:pcm:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T408318]
'''Updates for technical contributors'''
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.5|MediaWiki]]

'''In depth'''
* The Wikimedia Foundation is in the early stages of exploring approaches to '''Article guidance'''. The initiative aims to identify interventions that could help new editors easily understand and apply existing Wikipedia practices and policies when creating an article. The project is in the exploration and early experimental design phase. All community members are encouraged to [[mw:Special:MyLanguage/Article guidance|learn more]] about the project, and share their thoughts on [[mw:Special:MyLanguage/Talk:Article guidance|the talk page]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/49|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W49&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 18:58, 1 December 2025 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29732328 --&gt;

== Wikipedia translation of the week: 2025-50 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:ru:Сто лошадей]]'''&lt;br /&gt; &lt;small&gt;''([[:en:One Hundred Horses]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:A_Hundred_Steeds.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''One Hundred Horses''''' (Chinese: 百駿圖) is a Qing dynasty silk and ink painting by Giuseppe Castiglione. It was painted in 1728 for the Yongzheng emperor. The painting depicts a hundred horses in a variety of poses and activities, combining Western realism with traditional Chinese composition and brushwork.  

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:29, 8 December 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29719355 --&gt;

== Tech News: 2025-50 ==

&lt;section begin=&quot;technews-2025-W50&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/50|Translations]] are available.

'''Weekly highlight'''
* Anybody who wishes to secure their user account can now use [[m:Special:MyLanguage/Help:Two-factor authentication|two-factor authentication]] (2FA). This is available to all registered users of all Wikimedia projects. This is part of the [[mw:Special:MyLanguage/Product Safety and Integrity/Account Security|Account Security]] initiative. Later, 2FA will be required for all users who can take security- or privacy-sensitive actions.

'''Updates for editors'''
* Following last week's deployments, the [[mw:Special:MyLanguage/Help:Growth/Tools/Add a link|Add a link]] feature, which allows editors to add suggested links during editing, will be available to an additional [[Phab:T410469|33 Wikipedias]] starting on 9 December. This expansion is possible thanks to the new prediction model that now supports all languages, including those that were previously not covered. While the feature has been available on most Wikipedias for some time, this rollout brings us closer to using the improved model everywhere. If you have any questions or would like more details please contact [[mw:user:Trizek (WMF)|Trizek (WMF)]].
* Last week, the [[mw:Special:MyLanguage/Wikimedia Search Platform|Search Platform team]] added [[w:en:Transliteration|transliterated]] as-you-type search suggestions to Georgian wikis. If there are only a few regular search suggestions, then queries in Latin or Cyrillic script [[phab:T127003|are now rewritten into Georgian script]] to look for more matches. For example, searching for either &lt;bdi lang=&quot;ka-Latn&quot; dir=&quot;ltr&quot;&gt;''bedniereba''&lt;/bdi&gt; or &lt;bdi lang=&quot;ka-Cyrl&quot; dir=&quot;ltr&quot;&gt;''бедниереба''&lt;/bdi&gt; will now suggest the existing article about &lt;bdi lang=&quot;ka&quot; dir=&quot;ltr&quot;&gt;ბედნიერება&lt;/bdi&gt; (&quot;happiness&quot;). You can recommend other languages where transliterated suggestions would be useful [[phab:T375215|on Phabricator]] for future development.
* Later this week, a controlled experiment will begin for editors on the 100 largest Wikipedias who are editing a section in the mobile web visual editor. 50% of these editors will notice a new &quot;Edit full page&quot; button that will enable them to expand their editing session to the whole page. This feature is intended to make it easier for people on mobile web to edit any article section, regardless of which section-edit icon they tapped to begin. The experiment will last ~4 weeks. You can find [[phab:T409112|more details]] about the project.
* Later this week, the [[mw:Special:MyLanguage/Readers/Reader Growth|Reader Growth team]] will launch a [[mw:Special:MyLanguage/Readers/Reader Growth/WE3.1.14 Expanded Mobile Sections|mobile web experiment]] to expand all article sections by default (currently they are collapsed by default) and pin the section header the user is currently reading to the top of the page. The experiment will affect 10% of users on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias. [https://phabricator.wikimedia.org/T409485]
* The [[mw:Special:MyLanguage/Wikimedia Apps/Team/Wikipedia Year in Review/2025 Year in Review|Wikipedia Year in Review 2025]], a feature in the Wikipedia mobile apps (iOS and Android) that provides users with a personalised summary of their engagement with Wikipedia over the year, is now available on the iOS and Android apps. This edition includes expanded personalised insights, improved reading highlights, new donor messaging, and updated designs. Open the app to view your Year in Review and explore your reading journey from 2025.
* A recent software bug caused edits made with VisualEditor to make unintended changes to wikitext, including removing whitespace and replacing spaces with underscores in wikilinks inside citations. This was partially fixed last week, and further fixes are in progress. Editors who used VisualEditor between November 28 and December 2 should review their edits for unexpected modifications. [https://phabricator.wikimedia.org/T411238]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:23}} community-submitted {{PLURAL:23|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the incorrect handling of URLs copied from the address bar of Microsoft Edge users, has been resolved. [https://phabricator.wikimedia.org/T341281]

'''Updates for technical contributors'''
* Starting this week, users of the &quot;{{int:codemirror-beta-feature-title}}&quot; [[Special:Preferences#mw-prefsection-betafeatures|beta feature]] will have [[mw:Special:MyLanguage/Help:Extension:CodeMirror|CodeMirror]] as the editor for Lua, JavaScript, CSS, JSON and Vue content models, instead of [[mw:Special:MyLanguage/Extension:CodeEditor|CodeEditor]]. With this, the [[mw:Special:MyLanguage/Help:Extension:CodeMirror#Linting|linters]] will be upgraded. This is part of a larger effort to eventually replace CodeEditor and provide a consistent code editing experience. [https://phabricator.wikimedia.org/T373711]
* Developers are encouraged to take the [https://wikimediafoundation.limesurvey.net/552643 2025 Developer Satisfaction Survey], which remains open until 5 January 2026. If you build software for the Wikimedia ecosystem and would like to share your experiences or feedback, your participation is greatly appreciated. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/W4WBKO6Q55UWWCCSFWQATKEXBEHP3QNR/]
* There is no new MediaWiki version this week.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/50|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W50&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 17:46, 8 December 2025 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29738112 --&gt;

== Wikipedia translation of the week: 2025-51 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:First Universal Races Congress]]'''&lt;br /&gt; &lt;small&gt;''([[:fr:Premier Congrès universel des races]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Universal Races Congress seated outside the entrance to the Imperial Institute, London, 1911.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''First Universal Races Congress''' met in 1911 for four days at the University of London as an early effort at anti-racism. Speakers from a number of countries discussed race relations and how to improve them. The congress, with 2,100 attendees, was organised by prominent humanists of that era. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:56, 15 December 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29779168 --&gt;

== Tech News: 2025-51 ==

&lt;section begin=&quot;technews-2025-W51&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/51|Translations]] are available.

'''Updates for editors'''
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:18}} community-submitted {{PLURAL:18|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, one of the fixes addressed an issue for temporary accounts adding an external URL, which triggered an hCaptcha request in more cases than intended, and did not display the required popup on the first attempt to publish the edit. [https://phabricator.wikimedia.org/T411927]

'''Updates for technical contributors'''
* To improve database and site performance, external links to Wikimedia projects will no longer be stored in the database. This means they will not be searchable in [[{{#special:LinkSearch}}]], will not be checked by the Spam Blacklist or AbuseFilter as new links, and will not be in the &lt;code dir=ltr&gt;externallinks&lt;/code&gt; table on database replicas. In the future this may be extended to other highly-linked trusted websites on a per-wiki basis, such as Creative Commons links on Wikimedia Commons. [https://phabricator.wikimedia.org/T405005]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.7|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/51|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W51&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:03, 15 December 2025 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29796010 --&gt;

== Wikipedia translation of the week: 2025-52 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2025 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Pin Malakul]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Pin Malakul, January 1922.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Pin Malakul''' (24 October 1903 – 5 October 1995) was a Thai professor, educator and writer. His contributions to education in Thailand include the establishment of various institutions of higher education, the introduction of fixed class schedules, and the implementation of teacher-training programmes. In his career he served as Director-General of the Department of General Education, later becoming Permanent Secretary, and Minister, of Education. He was also a member of the executive board of UNESCO. His writings earned him the title of National Artist in 1987, and the 100th anniversary of his birth was celebrated by the UNESCO in 2003 as recognition of his contribution to the advancement of education in Thailand and Southeast Asia. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
-[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:26, 22 December 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29802495 --&gt;

== Tech News: 2025-52 ==

&lt;section begin=&quot;technews-2025-W52&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2025/52|Translations]] are available.

'''Updates for editors'''
* From January, edit filters [[mw:Special:MyLanguage/Extension:AbuseFilter/Access flags|can be set]] to automatically suppress their details such as rules and list of attempted edits and actions. This will help oversighters use edit filters to prevent doxxing or other suppressible material. [https://phabricator.wikimedia.org/T290324]
* The next issue of Tech News will be sent out on 12 January 2026 because of the end of year holidays. Thank you to all of the translators, and people who submitted content or feedback, this year.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:16}} community-submitted {{PLURAL:16|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the crash that occurred when tapping &quot;First Steps&quot; in the Wikipedia Android Year in Review has now been fixed, and the feature opens as expected. [https://phabricator.wikimedia.org/T411546]

'''Updates for technical contributors'''
* Interface elements such as diffs and categories generated by MediaWiki used to have the attribute &lt;code dir=ltr&gt;data-mw=&quot;interface&quot;&lt;/code&gt; to distinguish from wiki content. The attribute has been replaced with &lt;code dir=ltr&gt;data-mw-interface=&quot;&quot;&lt;/code&gt;, to avoid potential conflicts with other &lt;code dir=ltr&gt;data-mw&lt;/code&gt; attributes, which are generated by Parsoid. [https://phabricator.wikimedia.org/T409187]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] There is no new MediaWiki version this week or next week.
'''Meetings and events'''
* The [[mw:Wikimedia Hackathon Northwestern Europe 2026|Wikimedia Hackathon Northwestern Europe 2026]] will take place on 13-14 March 2026 in Arnhem, the Netherlands. Applications just opened mid-December and will close in mid-January or earlier if capacity is reached. With space for approximately 100 participants, early application is encouraged.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2025/52|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2025-W52&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:46, 22 December 2025 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29831856 --&gt;

== Wikipedia translation of the week: 2026-01 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:The Morning of the Magicians]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Le Matin des magiciens, couverture.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''The Morning of the Magicians: Introduction to Fantastic Realism''''' (French: Le Matin des magiciens: Introduction au réalisme fantastique) is a 1960 book by the journalists Louis Pauwels and Jacques Bergier. It covers topics like cryptohistory, ufology, occultism in Nazism, alchemy, spiritual philosophy. The second half of the book is entirely dedicated to the Nazi-Occult connections; the book is widely credited with the proliferation of numerous myths related to occultism in Nazism. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:20, 29 December 2025 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29802495 --&gt;

== Wikipedia translation of the week: 2026-02 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Somaliland War of Independence]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Somaliland, fighters of the Somali National Movement (SNM), 1980s.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Somaliland War of Independence''' was a rebellion waged by the Somali National Movement (SNM) against the ruling military junta in Somalia led by General Siad Barre lasting from its founding on 6 April 1981 and ended on 18 May 1991 when the SNM declared what was then northern Somalia independent as the Republic of Somaliland. The conflict served as the main theater of the larger Somali Rebellion that started in 1978. The conflict was in response to the harsh policies enacted by the Barre regime against the main clan family in Somaliland, the Isaaq, including a declaration of economic warfare on the clan-family. These harsh policies were put into effect shortly after the conclusion of the disastrous Ogaden War in 1978. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 03:00, 5 January 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29871911 --&gt;

== Wikipedia translation of the week: 2026-03 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Pietro Lauro]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Pietro Lauro]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Master I.A.V.F., Pietro Lauro, born 1508, Modenese Poet and Scholar (obverse), 1555, NGA 45072.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Pietro Lauro''', conosciuto anche come Pietro Lauro Modonese o Pietro Lauro da Modona (Modena o dintorni, 1510 circa – Venezia, 1568 circa) è stato un traduttore, scrittore e divulgatore scientifico italiano. Nonostante non si conosca gran parte della sua biografia, fu uno dei poligrafi italiani più conosciuti del Cinquecento. La sua produzione raccoglie traduzioni dal latino, dal greco e dallo spagnolo e riguardano opere di autori classici, stranieri e protestanti. Lauro si dimostrò abile nel trattare testi con temi molto diversi, come la filosofia, l'architettura, la medicina, il giardinaggio, l'agronomia, le scienze biologiche, la storia, la teologia e l'astronomia. Si cimentò anche nella scrittura di un poema cavalleresco sullo stile di quelli spagnoli, il Polendo, sua magnum opus in questo senso.

Aderente alla Riforma protestante, sebbene le sue trasposizioni siano state oggetto di critiche già degli autori a lui contemporanei, che le giudicarono troppo letterali, rozze e imparziali, a Lauro si deve il merito di aver ultimato la traduzione in lingua volgare di numerosi testi sia classici, sia scientifici, sia epistolari. I suoi lavori ebbero una notevole diffusione, non solo tra i letterati veneziani della sua epoca, ma in tutta Italia, tanto che alcune sue traduzioni vengono ancora oggi ristampate in nuove edizioni. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:45, 12 January 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29894468 --&gt;

== Tech News: 2026-03 ==

&lt;section begin=&quot;technews-2026-W03&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/03|Translations]] are available.

'''Weekly highlight'''
* The Wikimedia Foundation has shared some guiding questions for the July 2026–June 2027 Annual Plan on [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2026-2027/Product &amp; Technology OKRs|Meta]] and ''[[diffblog:2025/12/10/shaping-wikimedia-foundations-2026-2027-annual-goals-key-questions-for-the-wikimedia-movement/|Diff]]''. These focus on global trends, faster and healthier experimentation, better support for newcomers, strengthening editors and advanced users, improving collaboration across projects, and growing and retaining readership. Feedback and ideas are welcome on the [[m:Talk:Wikimedia Foundation Annual Plan/2026-2027|talk page]].

'''Updates for editors'''
* As part of the current work of Community Tech team on the [[m:Special:MyLanguage/Community Wishlist/W372|Multiple watchlists]] project, the display of [[Special:EditWatchlist|EditWatchlist]] will be updated as a first step towards multiple watchlists. Additionally, the pagination on [[Special:Search|Search]] will be updated too, as a part of the work on the [[m:Special:MyLanguage/Community Wishlist/W186|Revamp pagination / page navigation]] wish. [https://phabricator.wikimedia.org/T411596]
* [[m:Special:GlobalWatchlist|The Global Watchlist]] is a MediaWiki [[mw:Special:MyLanguage/Extension:GlobalWatchlist|extension]] that lets you see your watchlists from different wikis on the same page. It was recently updated to look more like the regular [[Special:Watchlist|Watchlist]], such as preparing it for temporary accounts in IP masking (including rerouting user links to contributions pages), making page titles bold, and opening links in edit summaries and tags in new browser tabs. [https://phabricator.wikimedia.org/T398361][https://phabricator.wikimedia.org/T298919][https://phabricator.wikimedia.org/T273526][https://phabricator.wikimedia.org/T286309]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:28}} community-submitted {{PLURAL:28|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the issue where global blocks did not have the option to disable sending emails, has now been fixed, and will be available for use in the week of January 13. [https://phabricator.wikimedia.org/T401293]

'''Updates for technical contributors'''
* The [[mw:Special:MyLanguage/VisualEditor/Citation tool|VisualEditor citation tool]] and [[mw:Special:MyLanguage/Help:Reference Previews|Reference Previews]] now support &quot;map&quot; as a reference type. [https://phabricator.wikimedia.org/T411083]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.10|MediaWiki]]/[[mw:MediaWiki 1.46/wmf.11|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/03|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W03&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:34, 12 January 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29907192 --&gt;

== Wikipedia translation of the week: 2026-04 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Volto di Palazzo Vecchio]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Piazza della signoria angolo via della ninna, palazzo vecchio, cantonata con testa scolpita 02.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
Il '''volto di Palazzo Vecchio''' (conosciuto anche come L'importuno o L'inopportuno) è un incisione su pietraforte attibuita a Michelangelo Buonarroti, scolpita in una delle pietre di Palazzo Vecchio a Firenze.

Secondo le varie leggende, il profilo sarebbe stato realizzato come graffito dall'artista toscano, con soggetto un suo importunatore, un debitore, un condannato a morte o se stesso. Nel 2020, gli studiosi hanno ipotizzato possa invece trattarsi di un ritratto di Francesco Granacci, pittore amico di Michelangelo. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:14, 19 January 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29945240 --&gt;

== Tech News: 2026-04 ==

&lt;section begin=&quot;technews-2026-W04&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/04|Translations]] are available.

'''Updates for editors'''
* The tray shown on [[Special:Diff|Special:Diff]] in mobile view has been redesigned. It is now collapsed by default, and incorporates a link to undo the edit being viewed, making it easier for mobile editors and reviewers to take action while keeping the interface uncluttered. [https://phabricator.wikimedia.org/T402297] 
* [[m:Special:GlobalWatchlist|The Global Watchlist]] lets you view your watchlists from multiple wikis on one page. The [[mw:Special:MyLanguage/Extension:GlobalWatchlist|extension]] continues to improve — it now automatically determines the text direction (ensuring correct display of sites with unusual domain names) and shows detailed descriptions for log actions. Later this week, a new permanent link for page creations and CSS classes for each entry element will be added. [https://phabricator.wikimedia.org/T412505][https://phabricator.wikimedia.org/T287929][https://phabricator.wikimedia.org/T262768][https://phabricator.wikimedia.org/T414135]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:32}} community-submitted {{PLURAL:32|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the previously observed issue in Vector 2022, where anchor link targets were obscured by the sticky header, has now been addressed. [https://phabricator.wikimedia.org/T406114]

'''Updates for technical contributors'''
* As mentioned in the [[m:Special:MyLanguage/Tech/News/2025/44|October 2025 deprecation announcement]], MediaWiki Interfaces team will begin sunsetting all transform endpoints containing a trailing slash from the MediaWiki REST API the week of January 26. Changes are expected to roll out to all wikis on or before January 30th. All API users currently calling them are encouraged to transition to the non-trailing slash versions. Both endpoint variations can be found, compared, and tested using the [https://test.wikipedia.org/wiki/Special:RestSandbox REST Sandbox]. If you have questions or encounter any problems, please file a ticket in Phabricator to the [https://phabricator.wikimedia.org/project/view/6931/ #MW-Interfaces-Team board].
* Interactive reference documentation for the [[mw:Special:MyLanguage/Wikimedia REST API|Wikimedia REST API]] has moved. Requests to API docs previously hosted through [[mw:Special:MyLanguage/RESTBase|RESTBase]] (e.g.: &lt;code dir=ltr&gt;https://en.wikipedia.org/api/rest_v1/&lt;/code&gt;) are now redirected to the [[w:en:Special:RestSandbox|REST Sandbox]].
* The [[mw:Special:MyLanguage/Wikidata Platform|WMF Wikidata Platform team]] (WDP) has published its [[d:Special:MyLanguage/Wikidata:Wikidata Platform team/Newsletter|January 2026 newsletter]]. It includes updates on the legacy full-graph endpoint decommissioning, the User-Agent policy change, the monthly Blazegraph migration office hours, and efforts to reduce regressions caused by the legacy endpoint shutdown. As a reminder, you can [[m:Special:MyLanguage/Global message delivery/Targets/WDP team updates|subscribe to the WDP newsletter]]!
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.12|MediaWiki]]

'''Meetings and events'''
* The [[mw:Wikimedia Hackathon Northwestern Europe 2026|Wikimedia Hackathon Northwestern Europe 2026]] will take place on 13-14 March 2026 in Arnhem, the Netherlands. Applications opened mid-December and will close soon or when capacity is reached. It's a two-day, technically oriented hackathon bringing together Wikimedians from the region. Hope to see you there!

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/04|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W04&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:30, 19 January 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29943403 --&gt;

== Wikipedia translation of the week: 2026-05 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Raffaello Kobayashi]]'''&lt;br /&gt; &lt;small&gt;''([[:en:Raffaello Kobayashi]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Raffaello Kobayashi''', nato Raffaele Sanzio (Bari, 14 gennaio 1917 – Yokohama, 1 aprile 2011), è stato un militare italiano naturalizzato giapponese.

Sommergibilista durante la Seconda guerra mondiale, prestò servizio per tutte e tre le principali Potenze dell'Asse: Regno d'Italia, Germania nazista e Impero giapponese. Alla fine della guerra si nascose in Giappone per evitare di subire l'internamento in un campo di prigionia, divenendo poi cittadino nipponico e cambiando il proprio nome.

Prese parte all'affondamento della HMS Calypso nel 1940, primo successo italiano in campo navale nel corso del conflitto mondiale. Con l'abbattimento di un bombardiere statunitense il 22 agosto 1945, otto giorni dopo il discorso di resa del Giappone alle potenze alleate della seconda guerra mondiale, a bordo del Comandante Cappellini, sarebbe stata l'ultima persona in assoluto a mettere fuori combattimento un velivolo degli Alleati nella stessa guerra. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:05, 26 January 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29945240 --&gt;

== Tech News: 2026-05 ==

&lt;section begin=&quot;technews-2026-W05&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/05|Translations]] are available.

'''Updates for editors'''
* Wikimedia Foundation invites comments on [[m:Special:MyLanguage/Product and Technology Advisory Council/Year1 Reflections and Proposed Way Forward 2026 Update|proposed future]] of the [[:m:Special:MyLanguage/Product and Technology Advisory Council|Product and Technology Advisory Council]] until 28 February.
* All users with registered accounts can now use passkeys for [[m:Special:MyLanguage/Help:Two-factor authentication|two-factor authentication]] (2FA). Passkeys are a simple way to log in without using a second device. They verify the user's identity using a fingerprint, face scan, or a PIN code. To set up a passkey, first set up a regular 2FA method. Currently, to log in with a passkey, users must also use a password. Later this quarter, passwordless login will allow users to log in with a single click and a passkey. Users with advanced rights will also be required to have 2FA enabled. This is part of the [[mw:Special:MyLanguage/Product Safety and Integrity/Account Security|Account Security]] project.
* Unregistered contributors on blocked IPs or blocked IP ranges can now interact on-wiki to appeal a block by creating a temporary account to appeal a block on the user talk page, unless the &quot;prevent this user from editing their own talk page&quot; is enabled. This solves the problem of logged-out users unable to use the default unblock process via user talk page. [https://phabricator.wikimedia.org/T398673]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:20}} community-submitted {{PLURAL:20|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the Two-Factor Authentication (2FA) methods description on the management page has been updated. It is now clearer and easier for users to understand and make use of. [https://phabricator.wikimedia.org/T332385]

'''Updates for technical contributors'''
* A new AbuseFilter variable, &lt;code&gt;account_type&lt;/code&gt;, has been added to provide a reliable way to determine the account type being created in the &lt;code&gt;createaccount&lt;/code&gt; and &lt;code&gt;autocreateaccount&lt;/code&gt; actions. As part of this change, the variable &lt;code&gt;accountname&lt;/code&gt; has been renamed to &lt;code&gt;account_name&lt;/code&gt;, and &lt;code&gt;accountname&lt;/code&gt; is now deprecated. Edit filter managers should update any filters that use hardcoded account type checks or the deprecated variable. [https://phabricator.wikimedia.org/T414049]
* Image thumbnails that are requested in non-standard sizes, and using non-standard methods such as direct requests to &lt;code dir=ltr&gt;&lt;nowiki&gt;upload.wikimedia.org/…&lt;/nowiki&gt;&lt;/code&gt; will stop working in the near future. This change is to prevent ongoing external abuse by web-scrapers and bots. Some users with custom CSS/JS, Interface Admins who can fix gadgets and local skins, and Tool-authors, will need to update their code to use standard thumbnail sizes. [[phab:T414805|Details, search-links, and examples of how to fix them, are available in the task]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.13|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/05|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W05&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:18, 26 January 2026 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=29969530 --&gt;

== Wikipedia translation of the week: 2026-06 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Censorship in the Czech Republic]]'''&lt;br /&gt; &lt;small&gt;''([[:cs:Cenzura v Česku]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Censorship in the Czech Republic''' had been highly active until 17 November 1989 and the fall of Communism in the former Czechoslovakia. Czech Republic was ranked as the 13th most free country in the World Press Freedom Index in 2014. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:32, 2 February 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29945240 --&gt;

== Tech News: 2026-06 ==

&lt;section begin=&quot;technews-2026-W06&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/06|Translations]] are available.

'''Updates for editors'''
* The &quot;{{int:pageinfo-toolboxlink}}&quot; feature, which gives validating information about a page ([{{fullurl:{{FULLPAGENAME}}|action=info}} example]), now automatically includes a table of contents. If there is a local [[{{ns:8}}:Pageinfo-header]] page created by individual users, it can now be removed. [https://phabricator.wikimedia.org/T363726]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:21}} community-submitted {{PLURAL:21|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, VisualEditor previously added bold or italic formatting inside link descriptions, making the wikicode complex. This has now been fixed. [https://phabricator.wikimedia.org/T409669]

'''Updates for technical contributors'''
* There was no XML dump on 20 January. Additionally, from now on, dumps will be generated once per month only. [https://phabricator.wikimedia.org/T414389]
* The MediaWiki Interfaces team removed support for all transform endpoints containing a trailing slash from the [https://www.mediawiki.org/wiki/Special:MyLanguage/API:REST%20API MediaWiki REST API]. All API users currently calling those endpoints are encouraged to transition to the non-trailing slash versions. If you have questions or encounter any problems, please file a ticket in phabricator to the [https://phabricator.wikimedia.org/project/view/6931/ #MW-Interfaces-Team board].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.14|MediaWiki]]

'''Weekly highlight'''
* Users are reminded that the Wikimedia Foundation has shared some guiding questions for the July 2026–June 2027 Annual Plan on [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2026-2027/Product &amp; Technology OKRs|Meta]] and ''[[diffblog:2025/12/10/shaping-wikimedia-foundations-2026-2027-annual-goals-key-questions-for-the-wikimedia-movement/|Diff]]''. These focus on global trends, faster and healthier experimentation, better support for newcomers, strengthening editors and advanced users, improving collaboration across projects, and growing and retaining readership. Feedback and ideas are welcome on the [[m:Talk:Wikimedia Foundation Annual Plan/2026-2027|talk page]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/06|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W06&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 17:44, 2 February 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30000986 --&gt;

== Wikipedia translation of the week: 2026-07 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Petites Heures of Jean de France, Duc de Berry]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Jacquemart de Hesdin 002.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Petites Heures of Jean de France, Duc de Berry''' is an illuminated book of hours commissioned by John, Duke of Berry between 1375 and 1385–90. It is known for its ornate miniature leaves and border decorations. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 03:59, 9 February 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29945240 --&gt;

== Tech News: 2026-07 ==

&lt;section begin=&quot;technews-2026-W07&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/07|Translations]] are available.

'''Updates for editors'''
* [[File:Maki-gift-15.svg|12px|link=|class=skin-invert|Wishlist item]] Logged-in contributors who manage large or complex watchlists can now organise and filter watched pages in ways that improve their workflows with the new [[mw:Special:MyLanguage/Help:Watchlist labels|Watchlist labels]] feature. By adding custom labels (for example: pages you created, pages being monitored for vandalism, or discussion pages) users can more quickly identify what needs attention, reduce cognitive load, and respond more efficiently. This improves watchlist usability, especially for highly active editors.
* A new feature available on [[Special:Contributions|Special:Contributions]] shows [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|temporary accounts]] that are likely operated by the same person, and so makes patrolling less time-consuming. Upon checking contributions of a temporary account, users with access to temporary account IP addresses can now see a view of contributions from the related temporary accounts. The feature looks up all the IPs associated with a given temporary account within the data retention period and shows all the contributions of all temporary accounts that have used these IPs. [[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts#February 2026: Improvements to the patroller tooling|Learn more]]. [https://phabricator.wikimedia.org/T415674] 
* When editors preview a wikitext edit, the reminder box that they are only seeing a preview (which is shown at the top), now has a grey/neutral background instead of a yellow/warning background. This makes it easier to distinguish preview notes from actual warnings (for example, edit conflicts or problematic redirect targets), which will now be shown in separate warning or error boxes. [https://phabricator.wikimedia.org/T414742]
* The [[m:Special:GlobalWatchlist|Global Watchlist]] lets you view your watchlists from multiple wikis on one page. The [[mw:Special:MyLanguage/Extension:GlobalWatchlist|extension]] continues to improve — it now properly supports more than one Wikibase site, for example both [[d:|Wikidata]] and [[testwikidata:|testwikidata]]. In addition, issues regarding text direction have been fixed for users who prefer Wikidata or other Wikibase sites in right-to-left (RTL) languages. [https://phabricator.wikimedia.org/T415440][https://phabricator.wikimedia.org/T415458]
* The automatic &quot;magic links&quot; for ISBN, RFC, and PMID numbers have been [[mw:Special:MyLanguage/Help:Magic links|deprecated in wikitext since 2021]] due to inflexibility and difficulties with localization. Several wikis have successfully replaced RFC and PMID magic links with equivalent external links, but a template was often required to replace the functionality of the ISBN magic link. There is now a new [[mw:Special:MyLanguage/Help:Magic words#isbn|built-in parser function]] &lt;code dir=ltr&gt;&lt;nowiki&gt;{{#isbn}}&lt;/nowiki&gt;&lt;/code&gt; available to replace the basic functionality of the ISBN magic link. This makes it easier for wikis who wish to migrate off of the deprecated magic link functionality to do so. [https://phabricator.wikimedia.org/T145604]
* Two new wikis have been created: 
** a {{int:project-localized-name-group-wikipedia}} in [[d:Q35401|Jju]] ([[w:kaj:|&lt;code&gt;w:kaj:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T413283]
** a {{int:project-localized-name-group-wikipedia}} in [[d:Q1186896|Nawat]] ([[w:ppl:|&lt;code&gt;w:ppl:&lt;/code&gt;]]) [https://phabricator.wikimedia.org/T413273]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:23}} community-submitted {{PLURAL:23|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. 

'''Updates for technical contributors'''
* A new global user group has been created: [[{{int:grouppage-local-bot}}|{{int:group-local-bot}}]]. It will be used internally by the software to allow community bots to bypass rate limits that are applied to abusive [[w:en:Web scraping|web scrapers]]. Accounts that are approved as bots on at least one Wikimedia wiki will be automatically added to this group. It will not change what user permissions the bot has. [https://phabricator.wikimedia.org/T415588]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.15|MediaWiki]]

'''Meetings and events'''
* The [[mw:Special:MyLanguage/MediaWiki Users and Developers Conference Spring 2026|MediaWiki Users and Developers Conference, Spring 2026]] will be held March 25–27 in Salt Lake City, USA. This event is organized by and for the third-party MediaWiki community. You can propose sessions and register to attend. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/AZBWVI46SDEB65PGR5J6E4TYOQQEZXM7/]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/07|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W07&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 23:31, 9 February 2026 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30026671 --&gt;

== Wikipedia translation of the week: 2026-08 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Lysmata grabhami]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Lysmata grabhami1.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''Lysmata grabhami''''' is a species of saltwater shrimp in the family Hippolytidae. It was first described by Gordon in 1935. It occurs in the tropical and subtropical Atlantic Ocean and is a cleaner shrimp, operating a cleaning station to which fish come to have parasites removed. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 13:45, 16 February 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=29945240 --&gt;

== Tech News: 2026-08 ==

&lt;section begin=&quot;technews-2026-W08&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/08|Translations]] are available.

'''Weekly highlight'''
* The [[mw:Special:MyLanguage/Wikimedia Site Reliability Engineering|SRE Team]] will be performing a cleanup of Wikimedia's [[m:Special:MyLanguage/Etherpad|Etherpad]] instance, the web-based editor for real-time collaborative document editing. All pads will be permanently deleted after 30 April, 2026 – if there are still migration projects in progress at that point the team can revisit the date on a case by case basis. Please create local backups of any content you wish to keep, as deleted data cannot be recovered. This cleanup helps reduce database size and minimize infrastructure footprint. Etherpad will continue to support real-time collaboration, but long-term storage should not be expected. Additional cleanups may occur in the future without prior notice. [https://phabricator.wikimedia.org/T415237]

'''Updates for editors'''
* The Information Retrieval team will be launching an [[mw:Special:MyLanguage/Readers/Information Retrieval/Phase 1|Android mobile app experiment]] that tests hybrid search capabilities which can handle both semantic and keyword queries. The improvement of on-platform search will enable readers to find what they’re looking for directly on Wikipedia more easily. The experiment will first be launched on Greek Wikipedia in late February, followed by English, French, and Portuguese in March. [https://diff.wikimedia.org/2026/01/08/semantic-search-making-it-easier-to-find-the-information-readers-want/ Read more] on Diff blog. [https://www.mediawiki.org/wiki/Readers/Information_Retrieval]
* The Reader Growth team will run [[mw:Special:MyLanguage/Readers/Reader Growth/WE3.10.2 Mobile Table of Contents|an experiment]] for mobile web users, that adds a table of contents and automatically expands all article sections, to learn more about navigation issues they face. The test will be available on Arabic, Chinese, English, French, Indonesian, and Vietnamese Wikipedias.
* Previously, site notices ([[{{ns:8}}:Sitenotice]] and [[{{ns:8}}:Anonnotice]]) would only render on the desktop site. Now, they will render on all platforms. Users on mobile web will now see these notices and be informed. Site administrators should be prepared to test and fix notices on mobile devices to avoid interference with articles. To opt out, interface admins can add &lt;code dir=&quot;ltr&quot;&gt;#siteNotice { display: none; }&lt;/code&gt; to [[{{ns:8}}:Minerva.css]]. [https://phabricator.wikimedia.org/T138572][https://phabricator.wikimedia.org/T416644]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:19}} community-submitted {{PLURAL:19|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue on [[Special:RecentChanges|Special:RecentChanges]] has been fixed. Previously, clicking hide in the active filters caused the &quot;view new changes since…&quot; button to disappear, though it should have remained visible. The button now behaves as expected. [https://phabricator.wikimedia.org/T406339]

'''Updates for technical contributors'''
* New documentation is now available to help editors debug on-site search features. It supports troubleshooting when pages do not appear in results, when ranking seems unexpected, and when you need to inspect what content is being indexed, helping make search behavior easier to understand and analyze. [[mw:Help:CirrusSearch/Debug|Learn more]]. [https://phabricator.wikimedia.org/T411169]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.16|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/08|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W08&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:17, 16 February 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30086330 --&gt;

== Wikipedia translation of the week: 2026-09 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Elefante di Cremona]]'''&lt;br /&gt; &lt;small&gt;''([[:de:Elefant von Cremona]])&amp;#32;([[:eo:Elefanto de Cremona]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Matthew Paris Elephant from Parker MS 16 fol 151v.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
L''''elefante di Cremona''' (Asia, prima del 1228 - Parma, gennaio 1248) fu un esemplare di elefante donato nel 1228 a Federico II di Svevia da parte del sultano ayyubide al-Malik al-Kamil durante gli incontri che porteranno alla Pace di Giaffa. Usato principalmente per le manifestazioni trionfali del sovrano, l'elefante è citato da numerosi cronachisti e testimoni dell'epoca ed è noto per aver trainato il Carroccio dopo la grande vittoria delle armate di Federico II nella battaglia di Cortenuova del 1237. Rimasto a lungo nell'immaginario popolare collettivo, l'animale venne ucciso durante alcuni scontri occorsi nelle settimane immediatamente precedenti alla battaglia di Parma. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 11:43, 23 February 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30097839 --&gt;

== Tech News: 2026-09 ==

&lt;section begin=&quot;technews-2026-W09&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/09|Translations]] are available.

'''Weekly highlight'''
* [[mw:Special:MyLanguage/Edit check/Reference Check|Reference Check]] has been deployed to English Wikipedia, completing its rollout across all Wikipedias. The feature prompts newcomers to add a citation before publishing new content, helping reduce common citation-related reverts and improve verifiability. In A/B testing, the impact was substantial: newcomers shown Reference Check were approximately 2.2 times more likely to include a reference on desktop and about 17.5 times more likely on mobile web. [https://analytics.wikimedia.org/published/reports/editing/reference_check_ab_test_report_final_2025.html]
'''Updates for editors'''
* The [[mw:Special:MyLanguage/Extension:InterwikiSorting|InterwikiSorting extension]], which allowed for the [[m:Special:MyLanguage/Interwiki sorting order|sorting of interwiki links]], has been undeployed from Wikipedia. As a result, editors who had enabled interwiki link sorting in non-compact mode (full list format) will now see links reordered. The links moving forward will be listed in the alphabetical order of language code. [https://phabricator.wikimedia.org/T253764]
* Later this week, people who are editing a page-section using the mobile visual editor, will notice a new &quot;Edit full page&quot; button. When tapped, you will be able to edit the entire article. This helps when the change you want to make is outside the section you initially opened. [https://phabricator.wikimedia.org/T387175][https://phabricator.wikimedia.org/T409112]
* [[mw:Special:MyLanguage/Readers/Reader Experience|The Reader Experience team]] is inviting editors to assess whether dark mode should still be considered &quot;beta&quot; on their wiki, based on their experience of how well it functions on desktop and mobile. If the feature is deemed mature, editors can update the interface messages in &lt;code dir=ltr&gt;MediaWiki:skin-theme-description&lt;/code&gt; and &lt;code dir=ltr&gt;MediaWiki:Vector-night-mode-beta-tag&lt;/code&gt; to indicate that dark mode is ready and no longer considered beta.
* The improved [[mw:Wikimedia_Apps/Team/iOS/Activity_Tab|Activity tab]] which displays user-insights is now available to all users of the Wikipedia iOS app (version 7.9.0 and later). Following earlier A/B testing that showed higher account creation among users with access to the feature, it has been rolled out to 100% of users along with some updates. The Activity tab now shows your edited articles in the timeline, offers editing impact insights like contribution counts and article view trends, and customization options to improve in-app experience for users.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:21}} community-submitted {{PLURAL:21|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, a bug that prevented [[mw:Special:MyLanguage/Extension:DiscussionTools|DiscussionTools]] from working on mobile has now been fixed, restoring full functionality. [https://phabricator.wikimedia.org/T415303]

'''Updates for technical contributors'''
* The [[m:Special:GlobalWatchlist|Global Watchlist]] lets you view your watchlists from multiple wikis on one page. The [[mw:Special:MyLanguage/Extension:GlobalWatchlist|extension]] that makes this possible continues to improve. The latest upgrade is the inclusion of a [[mw:Extension:GlobalWatchlist#hook|new hook]], &lt;code dir=ltr&gt;ext.globalwatchlist.rebuild&lt;/code&gt;, which fires after each watchlist rebuild. This allows you to run gadgets and user scripts for the Special page. [https://phabricator.wikimedia.org/T275159]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.17|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/09|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W09&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:04, 23 February 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30119102 --&gt;

== Wikipedia translation of the week: 2026-10 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Treaty of the Danish West Indies]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:The Virgin islands of the United States of America; historical and descriptive, commercial and industrial facts, figures, and resources (1918) (14596880870).jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Treaty of the Danish West Indies''' (Danish: Vestindiens traktat), officially the Convention between the United States and Denmark for cession of the Danish West Indies (Danish: Konventionen mellem USA og Danmark), was a 1916 treaty transferring sovereignty of the Danish West Indies from Denmark to the United States in exchange for a sum of US$25,000,000 in gold ($722 million in 2024) and a declaration from the United States that it would &quot;not object to the Danish Government extending their political and economic interests to the whole of Greenland&quot;. It is one of the most recent permanent expansions of United States territory.

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:43, 2 March 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30097839 --&gt;

== Tech News: 2026-10 ==

&lt;section begin=&quot;technews-2026-W10&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/10|Translations]] are available.

'''Weekly highlight'''
* Wikipedia 25 [[m:Special:MyLanguage/Wikipedia 25/Easter egg experiments|Birthday mode]] is now live on Betawi, Breton, Chinese, Czech, Dutch, English, French, Gorontalo, Indonesian, Italian, Luxembourgish, Madurese, Sicilian, Spanish, Thai, and Vietnamese Wikipedias! This limited-time campaign feature celebrates 25 years of Wikipedia with a birthday mascot, Baby Globe. When turned on, Baby Globe is shown on [[m:Special:MyLanguage/Wikipedia 25/Easter egg experiments/article configuration|~2,500 articles]], waiting to be discovered by readers. Communities can choose to turn Birthday mode on by getting consensus from their community and asking an admin to enable the feature and customize it via [[m:Special:MyLanguage/Wikipedia 25/Easter egg experiments#Community Configuration Demo|community configuration]] on the local wiki.

'''Updates for editors'''
* [[:m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing|Sub-referencing]], a new feature to re-use references with different details has been released to Swedish Wikipedia, Polish Wikipedia and [[:phab:T418209|a couple of other wikis]]. You can [[:m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing#test|try the feature]] on these projects or on testwiki and [https://en.wikipedia.beta.wmcloud.org/wiki/Sub-referencing betawiki]. Learnings from the first pilot wiki German Wikipedia have been [[:m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing/Learnings|published in a report]]. Reach out to the Wikimedia Deutschland team if you are [[:m:Talk:WMDE Technical Wishes/Sub-referencing#Pilot wikis|interested in becoming a pilot wiki]].
* [[mw:Special:MyLanguage/Help:Edit check#Paste check|Paste Check]] will become available at all Wikipedias this week. The feature prompts newcomers who are pasting text they are not likely to have written into VisualEditor to consider whether doing so risks a copyright violation. Paste Check [[mw:Special:MyLanguage/Edit check/Tags|tags]] all edits where it is shown for potential review. Local administrators can configure various aspects of the feature via [[{{#special:EditChecks}}]]. [[mw:Special:MyLanguage/Edit check/Paste Check#A/B Experiment|Research]] across 22 wikis found that Paste Check resulted in an 18% decrease in relative reverted-edits compared to the control group. Translators can [https://translatewiki.net/w/i.php?title=Special%3ATranslate&amp;group=ext-visualeditor-ve-mw-editcheck&amp;filter=&amp;optional=1&amp;action=translate help to localize] this and related features.
* The [[mw:Special:MyLanguage/Readers/Reader Experience|Reader Experience team]] will be standardizing the user menu in the top right for all mobile users so that it is closer to the desktop experience. Currently this user menu is only visible to users with Advanced Mobile Controls (AMC) turned on. The only change is that a couple buttons previously in the left-side menu will move to the top right for users who do not have AMC turned on. This change is expected to go out March 9 and seeks to improve the user interface. [https://phabricator.wikimedia.org/T413912]
* Starting in the week of March 2, the emails sent out when an email address was added, removed, or changed for an account will switch to a substantially nicer and clearer HTML email from the prior plaintext one. [https://phabricator.wikimedia.org/T410807]
* Notifications are currently limited to 2,000 historic entries per user, and extend back to 2013 when the feature was released. This is going to be changed to only store Notifications from the last 5 years, but up to 10,000 of them. This will help with long-term infrastructure health and help to prevent more recent notifications from disappearing too soon. [https://phabricator.wikimedia.org/T383948]
* The [[m:Special:GlobalWatchlist|Global Watchlist]] which lets you view your watchlists from multiple wikis on a single page continues to see improvements. The latest update improves label usage experience. The [[mw:Special:MyLanguage/Extension:GlobalWatchlist|extension]] now allows activating the [[mw:Special:MyLanguage/Manual:Language#Fallback languages|language fallback system]] for Wikidata items without labels in the viewed language, and showing those labels in the user’s preferred Wikidata language if no &lt;code dir=ltr&gt;uselang=&lt;/code&gt; URL parameter is provided. [https://phabricator.wikimedia.org/T373686][https://phabricator.wikimedia.org/T416111]
* The Wikipedia Android team has started a beta test of [[mw:Special:MyLanguage/Readers/Information Retrieval/Phase 1|hybrid search]] on Greek Wikipedia. Hybrid search capabilities can handle both semantic and keyword queries enabling readers to find what they’re looking for directly on Wikipedia more easily.
* For security reasons, members of certain user groups are [[m:Special:MyLanguage/Mandatory two-factor authentication for users with some extended rights|required to have two-factor authentication]] (2FA) enabled. Currently, 2FA is required to use the group, but not to be a member of it. Given that this model still has some vulnerabilities, the situation will [[phab:T418580|gradually change in March]]. Members of these groups will be unable to disable last 2FA method on their account, and it will be impossible to add users without 2FA to these groups. Users will still be able to add new authentication methods or remove them, as long as at least one method is continuously enabled. In the second half of March, users without 2FA will be removed from these groups. This applies to: CentralNotice administrators, checkusers, interface administrators, suppressors, Wikidata staff, Wikifunctions staff, WMF Office IT and WMF Trust &amp; Safety. Nothing will change for other users. See the linked task for deployment schedule. [https://phabricator.wikimedia.org/T418580]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the issue preventing users from creating an instance in [https://www.wikibase.cloud/ Wikibase.cloud] has now been fixed. [https://phabricator.wikimedia.org/T416807]

'''Updates for technical contributors'''
* To help ensure [[mw:Special:MyLanguage/MediaWiki Product Insights/Responsible Reuse|fair use of infrastructure]], over the next month the Wikimedia Foundation will implement global API rate limits across our APIs. In early March, stricter limits will be applied to unidentified requests from outside Toolforge/WMCS and API requests that are made from web browsers. In April, higher limits will be applied to identified traffic. These limits are intentionally set as high as possible to minimise impact on the community. Bots running in Toolforge/WMCS or with the bot user right on any wiki should not be affected for now. However, all developers are advised to follow updated best practices. For more information, see [[mw:Special:MyLanguage/Wikimedia APIs/Rate limits|Wikimedia APIs/Rate limits]].
* The Wikidata Query Service Linked Data Fragment (LDF) endpoint will be decommissioned in February. This endpoint served limited traffic, which was successfully migrated to other data access methods that were better suited to support existing use cases. The hardware used to support the LDF endpoint will be reallocated to support the ongoing backend migration efforts. [https://phabricator.wikimedia.org/T415696]
* The new Parsoid parser [[mw:Special:MyLanguage/Parsoid/Parser Unification/Updates|continues to be deployed to additional wikis]], improving platform sustainability and making it easier to introduce new reading and editing features. Parsoid is now the default parser on 488 WMF wikis (268 Wikipedias), now covering more than 10% of all Wikipedia page views.
* The process and criteria for [[Special:MyLanguage/Wikimedia Enterprise#Access|requesting exceptional access]] to the high volume feed of the ''Wikimedia Enterprise'' APIs (at no cost for mission-aligned usecases), [[m:Talk:Wikimedia Enterprise#Exceptional access criteria|have now been published]]. This is to provide more thorough and clearer documentation for users.
* [https://techblog.wikimedia.org/ Tech Blog], the blog dedicated to the Wikimedia technical community [https://techblog.wikimedia.org/2026/02/24/a-tech-blog-diff/ will be migrating] to [[diffblog:|Diff]], the community news and event blog. The migration should be complete in April 2026, after which new posts will be accepted for publishing. Readers will be able to access posts – old and new – on the landing page at https://diff.wikimedia.org/techblog.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.18|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/10|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W10&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 17:52, 2 March 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30137798 --&gt;

== Wikipedia translation of the week: 2026-11 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Steens Mountain]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Steens Mountain near Andrews, Oregon.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Steens Mountain''' is a large fault-block mountain in the northwest United States, located in Harney County, Oregon. Stretching some fifty miles (80 km) north to south, on its east side it rises from the Alvord Desert at an elevation of about 4,200 feet (1,280 m) to 9,738 feet (2,968 m) at the summit. Steens Mountain is not part of a mountain range but is properly a single mountain, the largest of Oregon's fault-block mountains. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 07:30, 9 March 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30097839 --&gt;

== Tech News: 2026-11 ==

&lt;section begin=&quot;technews-2026-W11&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/11|Translations]] are available.

'''Weekly highlight'''
* [[m:Special:MyLanguage/Tech/Server switch|All wikis will be read-only]] for a few minutes on Wednesday, 25 March 2026 at [https://zonestamp.toolforge.org/1774450800 15:00 UTC]. This is for the datacenter server switchover backup tests, [[wikitech:Deployments/Yearly calendar|which happen twice a year]]. During the switchover, all Wikimedia website traffic is shifted from one primary data center to the backup data center to test availability and prevent service disruption even in emergencies.
* Last week, all wikis had 2 hours of read-only time, and extended unavailability for user-scripts and gadgets. This was due to a security incident which has since been resolved. Work is ongoing to prevent re-occurrences. For current information please see the [[m:Steward's noticeboard#Statement on Meta about today's user script security incident|post on the Stewards' noticeboard]] ([[m:Special:MyLanguage/Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident|translations]]).

'''Updates for editors'''
* Users facing multiple blocks on mobile will now see the reasons for each block separately, instead of a generic message. This helps them understand why they are blocked and what steps they can take to resolve the issue. For example, users affected for using common VPNs (such as [[Special:MyLanguage/Apple iCloud Private Relay|iCloud Private Relay]]) will receive clearer guidance on what they need to do to start editing again. [https://phabricator.wikimedia.org/T357118]
* Later this week, [[mw:Special:MyLanguage/VisualEditor/Suggestion Mode|Suggestion Mode]] will become available as a beta feature within the visual editor at all Wikipedias. This feature proactively suggests various types of actions that people can consider taking to improve Wikipedia articles, and learn about related guidelines. The feature is locally configurable, and can also be locally expanded with custom Suggestions. Current settings can be seen at [[Special:EditChecks]] and there are [[mw:Special:MyLanguage/Help:Suggestion mode#For administrators %E2%80%93 local customization|instructions for how administrators can customize]] the links to point to local guidelines. The feature is connected to [[mw:Special:MyLanguage/Help:Edit check|Edit check]] which suggests improvements while someone is writing new content. In the future, the Editing team plans to evaluate the feature's impact with newcomers through a controlled experiment. [https://phabricator.wikimedia.org/T404600]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:23}} community-submitted {{PLURAL:23|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the issue where the cursor became misaligned during the use of CodeMirror’s syntax highlighting, which makes wikitext and code easier to read, has now been fixed. This problem specifically affected users who defined a font rule in a custom stylesheet while creating a new topic with DiscussionTools. [https://phabricator.wikimedia.org/T418793]

'''Updates for technical contributors'''
* API rate limiting update: To help ensure [[mw:Special:MyLanguage/MediaWiki Product Insights/Responsible Reuse|fair use of infrastructure]], global API rate limits will be applied this week to requests without a compliant User-Agent that originate from outside Toolforge/WMCS and to unauthenticated requests made from web browsers. Higher limits will be applied to identified traffic in April. Bots running in Toolforge/WMCS or with the bot user right on any wiki should not be affected for now. However, all developers are advised to follow updated best practices. For more information, see [[mw:Special:MyLanguage/Wikimedia APIs/Rate limits|Wikimedia APIs/Rate limits]].
* The new GraphQL API has been released. The API was developed as a flexible alternative to select features of the Wikidata Query Service (WDQS), to improve developer experience and foster adaptability, and efficient data access. Try it out and [[d:Wikidata:Wikibase GraphQL#Feedback and development|give feedback]]. You can also [https://greatquestion.co/wikimediadeutschland/GraphQLAPI/apply sign up for usability tests].
* The [[m:Special:MyLanguage/Product and Technology Advisory Council/Unsupported Tools Working Group|PTAC Unsupported Tools Working Group]] continued improvements to [[commons:Special:MyLanguage/Commons:Video2commons#|Video2Commons]] in February, with fixes addressing authentication errors, large-file handling, task queue visibility, and clearer upload behavior. Work is still ongoing in some areas, including changes related to deprecated server-side uploads. Read [[m:Special:MyLanguage/Product and Technology Advisory Council/Unsupported Tools Working Group#February 2026|this update]] to learn more.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.19|MediaWiki]]

'''In depth'''
* The Article Guidance team invites experienced Wikipedia editors from selected [[mw:Special:MyLanguage/Article guidance/Pilot wikis and collaborators#Collaborators|pilot wikis]] and interested contributors from other Wikipedias to fill out this questionnaire which is available in [https://docs.google.com/forms/d/e/1FAIpQLSfmLeVWnxmsCbPoI_UF2jyRcn73WRGWCVPHzerXb4Cz97X_Ag/viewform English], [https://docs.google.com/forms/d/e/1FAIpQLSd6rzr4XXQw8r4024fE3geTPFe13M_6w7Mitj-YJi0sOlWTAw/viewform?usp=header Arabic], [https://docs.google.com/forms/d/e/1FAIpQLSdok3-RfB18lcugYTUMGkpwmqG_8p760Wv4dCXitOXOszjUDw/viewform?usp=header Bengali], [https://docs.google.com/forms/d/e/1FAIpQLSfjTfYp4jEo0akA4B1e-Nfg3QZPCudUjhJzHzzDi6AHyAaMGA/viewform?usp=header Japanese], [https://docs.google.com/forms/d/e/1FAIpQLScteVoI29Aue4xc72dekk-6RYtvmMgQxzMI900UOawrFrSTWg/viewform?usp=header Portuguese], [https://docs.google.com/forms/d/e/1FAIpQLSetdxnYwL3ub2vqA7awCg5hJZPMIYcDPaiTe12rY9h0GYnVlw/viewform?usp=header Persian], and [https://docs.google.com/forms/d/e/1FAIpQLScNvfJF-Ot-4pzA4qAN771_0QDJ4Li19YcUsaTgSKW8Nc7U_Q/viewform?usp=header Turkish]. Your answers will help the team customize guidance for less experienced editors and help them learn community policies and practices while creating an article. Learn more [[mw:Special:MyLanguage/Article guidance|on the project page]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/11|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W11&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 18:53, 9 March 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30213008 --&gt;

== Wikipedia translation of the week: 2026-12 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Casque (anatomy)]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Great hornbill (Buceros bicornis) Photograph by Shantanu Kuveskar.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
A '''casque''' is an anatomical feature found in some species of birds, reptiles, and amphibians. In birds, it is an enlargement of the bones of the upper mandible or the skull, either on the front of the face, the top of the head, or both. The casque has been hypothesized to serve as a visual cue to a bird's sex, state of maturity, or social status; as reinforcement to the beak's structure; or as a resonance chamber, enhancing calls. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:43, 16 March 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30245038 --&gt;

== Tech News: 2026-12 ==

&lt;section begin=&quot;technews-2026-W12&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/12|Translations]] are available.

'''Updates for editors'''
* The [[mw:Special:MyLanguage/Help:Extension:CodeMirror|{{int:codemirror-beta-feature-title}}]] beta feature, also known as [[mw:Special:MyLanguage/Extension:CodeMirror|CodeMirror 6]], has been used for wikitext syntax highlighting since November 2024. It will be promoted out of beta by May 2026 in order to bring improvements and new [[mw:Special:MyLanguage/Help:Extension:CodeMirror#Features|features]] to all editors who use the standard syntax highlighter. If you have any questions or concerns about promoting the feature out of beta, [[mw:Special:MyLanguage/Help talk:Extension:CodeMirror|please share]]. [https://phabricator.wikimedia.org/T259059]
* Some changes to local user groups are performed by stewards on Meta-Wiki and logged there only. Now, interwiki rights changes will be logged both on Meta-Wiki and the wiki of the target user to make it easier to access a full record of user's rights changes on a local wiki. Past log entries for such changes will be backfilled in the coming weeks. [https://phabricator.wikimedia.org/T6055]
* On wikis using [[m:Special:MyLanguage/Flagged Revisions|Flagged Revisions]], the number of pending changes shown on [[{{#Special:PendingChanges}}]] previously counted pages which were no longer pending review, because they have been removed from the system without being reviewed, e.g. due to being deleted, moved to a different namespace, or due to wiki configuration changes. The count will be correct now. On some wikis the number shown will be much smaller than before. There should be no change to the list of pages itself. [https://phabricator.wikimedia.org/T413016]
* Wikifunctions composition language has been rewritten, resulting in a new version of the language. This change aims to increase service stability by reducing the orchestrator's memory consumption. This rewrite also enables substantial latency reduction, code simplification, and better abstractions, which will open the door to later feature additions. Read more about [[f:Special:MyLanguage/Wikifunctions:Status updates/2026-03-11|the changes]].
* Users can now sort search results alphabetically by page title. The update gives an additional option to finding pages more easily and quickly. Previously, results could be sorted by Edit date, Creation date, or Relevance. To use the new option, open 'Advanced Search' on the search results page and select 'Alphabetically' under 'Sorting Order'. [https://phabricator.wikimedia.org/T403775]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:28}} community-submitted {{PLURAL:28|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the bug that prevented UploadWizard on Wikimedia Commons from importing files from Flickr has now been fixed. [https://phabricator.wikimedia.org/T419263]
'''Updates for technical contributors'''
* A new special page, [[{{#special:LintTemplateErrors}}]], has been created to list transcluded pages that are flagged as containing lint errors to help users discover them easily. The list is sorted by the number of transclusions with errors. For example: [[{{#special:LintTemplateErrors}}/night-mode-unaware-background-color]]. [https://phabricator.wikimedia.org/T170874]
* Users of the [[mw:Special:MyLanguage/Help:Extension:CodeMirror|{{int:codemirror-beta-feature-title}}]] beta feature have been using [[mw:Special:MyLanguage/Extension:CodeMirror|CodeMirror]] instead of [[mw:Special:MyLanguage/Extension:CodeEditor|CodeEditor]] for syntax highlighting when editing JavaScript, CSS, JSON, Vue and Lua content pages, for some time now. Along with promoting CodeMirror 6 out of beta, the plan is to replace CodeEditor as the standard editor for these content models by May 2026. [[mw:Special:MyLanguage/Help talk:Extension:CodeMirror|Feedback or concerns are welcome]]. [https://phabricator.wikimedia.org/T419332]
* The [[mw:Special:MyLanguage/Extension:CodeMirror|CodeMirror]] JavaScript modules will soon be upgraded to CodeMirror 6. Leading up to the upgrade, loading the &lt;code dir=ltr&gt;ext.CodeMirror&lt;/code&gt; or &lt;code dir=ltr&gt;ext.CodeMirror.lib&lt;/code&gt; modules from gadgets and user scripts was deprecated in July 2025. The use of the &lt;code dir=ltr&gt;ext.CodeMirror.switch&lt;/code&gt; hook was also deprecated in March 2025. Contributors can now make their scripts or gadgets compatible with CodeMirror 6. See the [[mw:Special:MyLanguage/Extension:CodeMirror#Gadgets and user scripts|migration guide]] for more information. [https://phabricator.wikimedia.org/T373720]
* The MediaWiki Interfaces team is expanding coverage of REST API module definitions to include [[mw:Special:MyLanguage/API:REST API/Extensions|extension APIs]]. REST API modules are groups of related endpoints that can be independently managed and versioned. Modules now exist for [https://phabricator.wikimedia.org/T414470 GrowthExperiments] and [https://phabricator.wikimedia.org/T419053 Wikifunctions] APIs. As we migrate extension APIs to this structure, documentation will move out of the main MediaWiki OpenAPI spec and REST Sandbox view, and will instead be accessible via module-specific options in the dropdown on the [https://test.wikipedia.org/wiki/Special:RestSandbox REST Sandbox] (i.e., [[{{#Special:RestSandbox}}]], available on all wiki projects).
* The [[mw:Special:MyLanguage/Extension:Scribunto|Scribunto]] extension provides different pieces of information about the wiki where the module is being used via the [[mw:Special:MyLanguage/Extension:Scribunto/Lua reference manual|mw.site]] library. Starting last week, the library also provides a [[mw:Special:MyLanguage/Extension:Scribunto/Lua reference manual#mw.site.wikiId|way]] of accessing the [[mw:Special:MyLanguage/Manual:Wiki ID|wiki ID]] that can be used to facilitate cross-wiki module maintenance. [https://phabricator.wikimedia.org/T146616]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.20|MediaWiki]]

'''In depth'''
* The [[m:Special:MyLanguage/Coolest Tool Award|2026 Coolest Tool Award]] celebrating outstanding community tools, is now open for nominations! Nominate your favorite tool using the [https://wikimediafoundation.limesurvey.net/435684?lang=en nomination survey] form by 23 March 2026. For more information on privacy and data handling, please see the [[foundation:Special:MyLanguage/Legal:Coolest_Tool_Award_2026_Survey_Privacy_Statement|survey privacy statement]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/12|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W12&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:36, 16 March 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30260505 --&gt;

== Wikipedia translation of the week: 2026-13 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Etruscan sculpture]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Frontone A del grande tempio di luni con concilio degli dei, 175-150 ac. ca. 01.JPG|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Etruscan sculpture''' was one of the most important artistic expressions of the Etruscan people, who inhabited the regions of Northern Italy and Central Italy between about the 9th century BC and the 1st century BC. Etruscan art was largely a derivation of Greek art, although developed with many characteristics of its own. Given the almost total lack of Etruscan written documents, a problem compounded by the paucity of information on their language—still largely undeciphered—it is in their art that the keys to the reconstruction of their history are to be found, although Greek and Roman chronicles are also of great help. Like its culture in general, Etruscan sculpture has many obscure aspects for scholars, being the subject of controversy and forcing them to propose their interpretations always tentatively, but the consensus is that it was part of the most important and original legacy of Italian art and even contributed significantly to the initial formation of the artistic traditions of ancient Rome. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:07, 23 March 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30245038 --&gt;

== Tech News: 2026-13 ==

&lt;section begin=&quot;technews-2026-W13&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/13|Translations]] are available.

'''Weekly highlight'''
* Wikimedia site users can now log in without a password using passkeys. This is a secure method supported by fingerprint, facial recognition, or PIN. With this change, all users who opt for passwordless login will find it easier, faster, and more secure to log in to their accounts using any device. The new passkey login option currently appears as an autofill suggestion in the username field. An additional [[phab:T417120|&quot;Log in with passkey&quot; button]] will soon be available for users who have already registered a passkey. This update will improve security and user experience. The [[c:File:Passwordless_login_screencast.webm|screen recording]] demonstrates the passwordless login process step by step.
* [[m:Special:MyLanguage/Tech/Server switch|All wikis will be read-only]] for a few minutes on Wednesday, 25 March 2026 at [https://zonestamp.toolforge.org/1774450800 15:00 UTC]. This is for the datacenter server switchover backup tests, [[wikitech:Deployments/Yearly calendar|which happen twice a year]]. During the switchover, all Wikimedia website traffic is shifted from one primary data center to the backup data center to test availability and prevent service disruption even in emergencies.

'''Updates for editors'''
* Wikimedia site users can now export their notifications older than 5 years using a [[toolforge:echo-chamber|new Toolforge tool]]. This will ensure that users retain their important notifications and avoid them being lost based on the planned change to delete notifications older than 5 years, as previously announced. [https://phabricator.wikimedia.org/T383948]
* Wikipedia editors in Indonesian, Thai, Turkish, and Simple English now have access to Special:PersonalDashboard. This is an [[mw:Special:MyLanguage/Moderator Tools/Dashboard|early version of an experience]] that introduces newer editors to patrolling workflows, making it easier for them to move from making edits to participating in more advanced moderation work on their project. [https://phabricator.wikimedia.org/T402647]
* The [[Special:Block]] now has two minor interface changes. Administrators can now easily perform indefinite blocks through a dedicated radio button in the expiry section. Also, choosing an indefinite expiry provides a different set of common reasons to select from, which can be changed at: [[MediaWiki:Ipbreason-indef-dropdown]]. [https://phabricator.wikimedia.org/T401823]
* Mobile editors [[mw:Special:MyLanguage/Contributors/Account Creation Experiments#Logged-out|at several wikis]] can now see an improved logged-out edit warning, thanks to the recent updates from the Growth team. These changes released last week are part of ongoing efforts and tests to enhance [[mw:Special:MyLanguage/Contributors/Account Creation Experiments|account creation experience on mobile]] and then increase participation. [https://phabricator.wikimedia.org/T408484]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:36}} community-submitted {{PLURAL:36|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the bug that prevented mobile web users from seeing the block information when affected by multiple blocks has been fixed. They can now see messages of all the blocks currently affecting them when they access Wikipedia.

'''Updates for technical contributors'''
* Images built using Toolforge will soon get the upgraded buildpacks version, bringing support for newer language versions and other upstream improvements and fixes. If you use Toolforge Build Service, review the recent [https://lists.wikimedia.org/hyperkitty/list/cloud-announce@lists.wikimedia.org/thread/EMYTA32EV2V5SQ2JIEOD2CL66YFIZEKV/ cloud-announce email] and update your build configuration as necessary to ensure your tools are compatible. [https://wikitech.wikimedia.org/w/index.php?title=Help:Toolforge/Building_container_images&amp;oldid=2392097#Buildpack_environment_upgrade_process][https://phabricator.wikimedia.org/T380127]

* The [https://api.wikimedia.org/wiki/Main_Page API Portal] documentation wiki will shut down in June 2026. API keys created on the API Portal will continue to work normally. api.wikimedia.org endpoints will be deprecated gradually starting in July 2026. Documentation on the API Portal is moving to [[mw:Wikimedia APIs|mediawiki.org]]. Learn more on the [[wikitech:API Portal/Deprecation|project page]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.21|MediaWiki]]

'''In depth'''
* [[m:Special:MyLanguage/WMDE Technical Wishes|WMDE Technical Wishes]] is considering improvements to [[m:WMDE Technical Wishes/References/VisualEditor automatic reference names|automatically generated reference names in VisualEditor]]. Please check out the [[m:WMDE Technical Wishes/References/VisualEditor automatic reference names#Proposed solutions|proposed solutions]] and participate in the [[m:Talk:WMDE Technical Wishes/References/VisualEditor automatic reference names#Request for comment|request for comment]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/13|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W13&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 16:51, 23 March 2026 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30268305 --&gt;

== Wikipedia translation of the week: 2026-14 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Pulse (nightclub)]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Orlando FL Pulse Nightclub01.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Pulse''' was a gay bar, dance club, and nightclub in Orlando, Florida, founded in 2004 by Barbara Poma and Ron Legler. On June 12, 2016, the club was the scene of the second-deadliest mass shooting by a single gunman in U.S. history, and the second-deadliest terrorist attack on U.S. soil since the September 11 attacks. Forty-nine people were killed and 58 other people were injured. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:37, 30 March 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30306870 --&gt;

== Tech News: 2026-14 ==

&lt;section begin=&quot;technews-2026-W14&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/14|Translations]] are available.

'''Weekly highlight'''
* The Beta version of [[abstract:|Abstract Wikipedia]] a new Wikimedia project which is language-independent, was launched last week. The project allows communities to build Wikipedia articles in their native language, which can be readily accessed by other users in their own languages. The wiki is powered by instructions from Wikifunctions and also based on structured content from Wikidata. [[:f:Special:MyLanguage/Wikifunctions:Status updates/2026-03-26|Read more]].

'''Updates for editors'''
* The Growth team is running an A/B test to evaluate a clearer, more user-friendly message that promotes account creation on wikis. Currently when logged-out mobile users begin editing, they see a jarring warning message that can feel abrupt and discouraging. This also presents temporary account editing as the default rather than encouraging account creation. The test is running on ten Wikipedias, including Arabic, French, Spanish and German. [[mw:Special:MyLanguage/Contributors/Account Creation Experiments#2. Improve logged-out warning message (T415160)|Read more]].
* The Wikimedia Apps team is inviting feedback on [[mw:Special:MyLanguage/Wikimedia Apps/Team/Future of Editing on the Mobile Apps|how editing should work on the Wikipedia mobile apps]]. The discussion focuses on improving how users access editing tools when they tap &quot;Edit&quot;. This is part of a broader effort to convert readers who develop an interest in editing, to access a more user-friendly pathway to start contributing.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:45}} community-submitted {{PLURAL:45|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where citation fetching from the large newspaper archive [https://www.newspapers.com Newspapers.com] was no longer working, due to a block in [[mw:Special:MyLanguage/Citoid|Citoid]] requests, has now been fixed. [https://phabricator.wikimedia.org/T419903]

'''Updates for technical contributors'''
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.22|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/14|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W14&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:26, 30 March 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30329462 --&gt;

== Wikipedia translation of the week: 2026-15 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Tofana di Rozes]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Tofana di Rozes 04.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Tofana di Rozes''' (3,225 metres (10,581 ft)) is a mountain of the Dolomites in the Province of Belluno, Veneto, Italy. Located west of the resort of Cortina d'Ampezzo, the mountain's giant three-edged pyramid shape and its vertical south face, above the Falzarego Pass, makes it the most popular peak in the Tofane group, and one of the most popular in the Dolomites. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 12:27, 6 April 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30306870 --&gt;

== Tech News: 2026-15 ==

&lt;section begin=&quot;technews-2026-W15&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/15|Translations]] are available.

'''Updates for editors'''

* The [[mw:Special:MyLanguage/Help:Extension:CampaignEvents|CampaignEvents extension]] now includes a new group goal-setting feature, enabling organizers to set and track event goals such as the number of articles created and participating contributors in real time. Similarly, participants can work toward shared targets and see their collective impact as the event unfolds. The feature is now available on all Wikimedia wikis. Learn more in [[mw:Special:MyLanguage/Help:Extension:CampaignEvents/Registration/Collaborative contributions#Goal setting|the documentation]].
* [[File:Maki-gift-15.svg|12px|link=|class=skin-invert|Wishlist item]] The new [[mw:Special:MyLanguage/Help:Watchlist labels|watchlist labels]] feature (announced in [[m:Special:MyLanguage/Tech/News/2026/07|Tech News 2026-07]]) is now available via VisualEditor, the source editor, and the 'watchstar' (or watch link, for skins that don't have a star icon). Previously it was only possible to assign labels via [[Special:EditWatchlist|EditWatchlist]]. In all three places it is a new field following the expiry field.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:23}} community-submitted {{PLURAL:23|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the issue where talk pages on mobile with Parsoid are unusable after empty section headers, has now been fixed. [https://phabricator.wikimedia.org/T419171]

'''Updates for technical contributors'''
* The [[m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing|sub-referencing feature]], which lets editors add details to an existing reference without duplicating it, will be gradually rolled out to [[phab:T414094|more wikis]] later this year. Wikis using the [[mw:Special:MyLanguage/Reference Tooltips|Reference Tooltips]] gadget are encouraged to update their version (typically at [[m:MediaWiki:Gadget-ReferenceTooltips.js|MediaWiki:Gadget-ReferenceTooltips.js]] as shown [https://en.wikipedia.org/w/index.php?diff=1344408362 here]) to ensure compatibility. Other reference-related gadgets may also be affected. [https://phabricator.wikimedia.org/T416304]
* All Wikinews editions will be closed and switched to read-only mode on 4 May 2026. Content will remain accessible, but no new edits or articles can be added. This closure was approved by the Board of Trustees of the Wikimedia Foundation following extended discussions. [[m:Wikimedia Foundation Board noticeboard#Board of Trustees Approves Closure of Wikinews|Read more]].
* The [[:mw:Special:MyLanguage/API:Action API|Action API]] has had several formats for requested output. One of them, &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;format=php&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;, is being removed soon. Please ensure your scripts or bots use the [[mw:Special:MyLanguage/API:Data formats#Output|JSON format]]. This removal should affect very few scripts and bots. [https://phabricator.wikimedia.org/T118538]
* The [[Special:NamespaceInfo|Special:NamespaceInfo]] page now includes namespace aliases. For example &quot;WP&quot; for the &quot;Project&quot; (&quot;Wikipedia&quot;) namespace on the German Wikipedia. [https://phabricator.wikimedia.org/T381455]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.23|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/15|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W15&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 16:19, 6 April 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30362761 --&gt;

== Wikipedia translation of the week: 2026-16 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Very-low-calorie diet]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Green smoothie (8222465502).jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
A '''very-low-calorie diet''' (VLCD), also known as semistarvation diet and crash diet, is a type of diet with very or extremely low daily food energy consumption. VLCDs are defined as a diet of 800 kilocalories (3,300 kJ) per day or less. Modern medically supervised VLCDs use total meal replacements, with regulated formulations in Europe and Canada which contain the recommended daily requirements for vitamins, minerals, trace elements, fatty acids, protein and electrolyte balance. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:56, 13 April 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30306870 --&gt;

== Tech News: 2026-16 ==

&lt;section begin=&quot;technews-2026-W16&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/16|Translations]] are available.

'''Weekly highlight'''
* Experienced editors are invited to [https://b24e11a4f1.catalyst.wmcloud.org/wiki/Main_Page test] the [[mw:Special:MyLanguage/Article guidance|Article guidance]] feature, designed to help less-experienced editors create well-structured, policy-compliant Wikipedia articles. Testing instructions are [[mw:Special:MyLanguage/Article guidance/Test feature guide|available]]. Also, after reviewing [https://b24e11a4f1.catalyst.wmcloud.org/wiki/Category:Pages_using_article_guidance the outlines], please provide feedback on the [[mw:Talk:Article guidance|project talk page]]. Based on your input, the feature will be refined and transferred to the pilot Wikipedias to translate and adapt. Check out [[c:File:Article Guidance workflow demo - April 2026.webm|the video]] explaining the feature.
'''Updates for editors'''
* On most wikis, all autoconfirmed users can now use [[Special:ChangeContentModel|Special:ChangeContentModel]] page to [[mw:Special:MyLanguage/Help:ChangeContentModel|create new pages with custom content models]], such as mass message lists, making custom page formats more accessible. Check [[Special:ListGroupRights|Special:ListGroupRights]] for the status of your wiki. [https://phabricator.wikimedia.org/T248294]
* The Growth team has launched an [[mw:Special:MyLanguage/Contributors/Account_Creation_Experiments|account creation experiment]] to evaluate whether adding an account creation button to the mobile web header increases new account registrations and encourages more mobile users to contribute to the wikis. The experiment is currently live on Hindi, Indonesian, Bengali, Thai, and Hebrew Wikipedia, and targets 10% of logged-out mobile web users.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:30}} community-submitted {{PLURAL:30|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where VisualEditor could get stuck loading on Windows devices with animations turned off, has now been fixed. [https://phabricator.wikimedia.org/T382856]

'''Updates for technical contributors'''
* Starting later this week, {{int:group-abusefilter}} who have the [[mw:Special:MyLanguage/Help:Extension:CodeMirror|{{int:codemirror-beta-feature-title}}]] beta feature enabled will have [[mw:Special:MyLanguage/Extension:CodeMirror|CodeMirror]] instead of [[mw:Special:MyLanguage/Extension:CodeEditor|CodeEditor]] as the editor at [[Special:AbuseFilter|Special:AbuseFilter]]. This is part of the broader effort to make the user experience more consistent across all editors. [https://phabricator.wikimedia.org/T399673][https://phabricator.wikimedia.org/T419332]
* Tools and bots that access the [[mw:Special:MyLanguage/Notifications/API|Notifications API]] (&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;action=query&amp;meta=notifications&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;) will need to update their OAuth or BotPassword grants to also include access to private notifications. [https://phabricator.wikimedia.org/T421991]
* Due to a library upgrade, listings on category pages may be displayed out of order starting on Monday, 20th April. A migration script will be run to correct this, and will take hours to days depending on the size of the wiki (up to a week for English Wikipedia). [https://phabricator.wikimedia.org/T422544]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.24|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/16|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W16&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 15:19, 13 April 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30380527 --&gt;

== Wikipedia translation of the week: 2026-17 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Chromodoris willani]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Babosa de mar (Chromodoris willani), Anilao, Filipinas, 2023-08-24, DD 34.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''''Chromodoris willani''''', commonly known as Willan's chromodoris, is a species of sea slug, a dorid nudibranch, a shell-less marine gastropod mollusk in the family Chromodorididae. The species is named for the renowned nudibranch taxonomist Dr. Richard C. Willan. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:34, 20 April 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30430366 --&gt;

== Tech News: 2026-17 ==

&lt;section begin=&quot;technews-2026-W17&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/17|Translations]] are available.

'''Weekly highlight'''
* After two years of development, [[mw:Special:MyLanguage/Help:Extension:CodeMirror|{{int:codemirror-beta-feature-title}}]], also known as [[mw:Special:MyLanguage/Extension:CodeMirror|CodeMirror 6]], is to be promoted out of beta on Tuesday, April 21. It brings better code and wikitext readability, reduction in typing errors, and other [[mw:Special:MyLanguage/Help:Extension:CodeMirror|benefits]] to all users of the standard syntax highlighter. A huge thank you to volunteer [https://phabricator.wikimedia.org/p/Bhsd/ Bhsd] who developed many of the new features, including [[mw:Special:MyLanguage/Help:Extension:CodeMirror#Code folding|code folding]], [[mw:Special:MyLanguage/Help:Extension:CodeMirror#Autocompletion|autocompletion]], and [[mw:Special:MyLanguage/Help:Extension:CodeMirror#Linting|linting]]. [https://phabricator.wikimedia.org/T259059]
* A major update to the Wikipedia app for iOS is now rolling out, redesigning the interface to align with Apple's latest &quot;Liquid Glass&quot; visual design. [https://apps.apple.com/us/app/wikipedia/id324715238 Download the latest version] and explore the update.

'''Updates for editors'''
* [[mw:Special:MyLanguage/Readers/Reader Experience/WE3.3.4 Reading lists|Reading lists]] is a feature which allows readers to save articles to a list for reading later. This feature is now in beta on Arabic, French, Indonesian, Vietnamese, and Chinese Wikipedias and by default for all new accounts on all Wikipedias.
* An experiment which explores extending [[mw:Special:MyLanguage/Readers/Reader Growth/Mobile page previews|Page Previews to mobile web]] will be launched in the week of April 20 on Arabic, English, French, Italian, Polish, and Vietnamese Wikipedias. Page Previews are pop-ups that display a thumbnail, lead paragraph, and a link to open the full article of a blue link, thereby improving content discovery. The feature is already available on desktop and in the apps. [[m:Special:MyLanguage/List of experiments in Product and Technology#Template|Read more about this experiment and others]].
* On several wikis, logged-in editors who haven't [[mw:Special:MyLanguage/Help:Email confirmation|confirmed their email addresses]] can now see a banner encouraging them to do so. Having the email address confirmed allows a user to restore access to the account if they lose it. [[mw:Special:MyLanguage/Product Safety and Integrity/Account Security#Encouraging users to confirm their email addresses|Learn more]]. [https://phabricator.wikimedia.org/T421366]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:15}} community-submitted {{PLURAL:15|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where editing very large wiki pages in the 2017 wikitext editor caused slow loading, preview and scrolling lag, and performance issues when selecting, cutting, or pasting content, has now been fixed. [https://phabricator.wikimedia.org/T184857]

'''Updates for technical contributors'''
* As part of the promotion of [[mw:Special:MyLanguage/Help:Extension:CodeMirror|CodeMirror]] from a beta feature, all users will use [[mw:Special:MyLanguage/Extension:CodeMirror|CodeMirror]] instead of [[mw:Special:MyLanguage/Extension:CodeEditor|CodeEditor]] for syntax highlighting when editing JavaScript, CSS, JSON, Vue and Lua content pages. [https://phabricator.wikimedia.org/T419332]
* The &lt;code&gt;mirrors.wikimedia.org&lt;/code&gt; service for Debian and Ubuntu users will sunset and stop working on May 15. The resources for the service will be replaced with new and better options. Some users may need to switch to a different server which should take about a minute. [https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/LJYRIS4WB66HIRCAO4GIDTXCMDVZRBMA/ You can read more]. [https://phabricator.wikimedia.org/T416707]
* The &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;image&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;oldimage&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; table will be removed from [[wikitech:Help:Wiki Replicas|wikireplicas]]. If your tools or queries access &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;image&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; or &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;oldimage&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; directly, please update them to use the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;file&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;filerevision&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; table before 28 May. [https://phabricator.wikimedia.org/T28741]
* Following the recent implementation of global API rate limits on unidentified traffic, the Wikimedia Foundation will continue efforts to ensure [[mw:Special:MyLanguage/MediaWiki Product Insights/Responsible Reuse|fair use of infrastructure]] by applying global limits to identified API traffic beginning the last week of April. These limits are intentionally set as high as possible to minimise impact on the community. Bots running in Toolforge/WMCS or with the bot user right on any wiki should not be affected for now. However, all developers are advised to follow updated best practices. For more information, see [[mw:Special:MyLanguage/Wikimedia APIs/Rate limits|Wikimedia APIs/Rate limits]] and [[mw:Special:MyLanguage/Wikimedia APIs/Rate limits/FAQ|Frequently Asked Questions]].
* The [[mw:Special:MyLanguage/Attribution API|Attribution API]] is now available as a [[mw:Special:MyLanguage/Wikimedia APIs/Stability policy|beta]]. The API fetches information for crediting Wikimedia articles and media files wherever they are used. Reference documentation is available through the REST Sandbox special page available on all Wikimedia wikis (such as the [https://en.wikipedia.org/w/index.php?api=attribution.v0-beta&amp;title=Special%3ARestSandbox REST sandbox on English Wikipedia]). Share your feedback on the [[mw:Talk:Attribution API|project talk page]].
* There is no new MediaWiki version this week.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/17|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W17&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 15:01, 20 April 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30432763 --&gt;

== Wikipedia translation of the week: 2026-18 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Platypus venom]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Platypus spur.JPG|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The platypus is one of the few living mammals to produce venom. The venom is made in venom glands that are connected to hollow spurs on their hind legs; it is primarily made during the mating season.[1] While the venom's effects are described as extremely painful, it is not lethal to humans. Many archaic mammal groups possess similar tarsal spurs, so it is thought that, rather than having developed this characteristic uniquely, the platypus simply inherited this characteristic from its ancestors. Rather than being a unique outlier, the platypus is the last demonstration of what was once a common mammalian characteristic, and it can be used as a model for non-therian mammals and their venom delivery and properties. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:04, 27 April 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30449041 --&gt;

== Tech News: 2026-18 ==

&lt;section begin=&quot;technews-2026-W18&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/18|Translations]] are available.

'''Updates for editors'''
* There is a change in how new users are autoconfirmed that will improve anti-vandalism protection. Currently, users who have had an account for a few days and made a few edits are automatically added to the [[{{int:grouppage-autoconfirmed/{{CONTENTLANGUAGE}}}}|{{int:group-autoconfirmed}}]] group. This configuration tends to be exploited by some vandals, who create accounts and start to use them only after some time. To mitigate this, the configuration will be updated next week so that – for the purpose of becoming autoconfirmed – the account age will be counted from their first edit, instead of registration date. The numeric value of the age threshold will remain the same. This change will be deployed only to wikis which require at least one edit as part of the autoconfirmation conditions. [https://phabricator.wikimedia.org/T418484]
* All Wikipedia users with new accounts and those who activated the &quot;automatically enable most beta features&quot; option in their preference can now use the [[mw:Special:MyLanguage/Readers/Reader Experience/WE3.3.4 Reading lists|reading lists]] beta feature to save articles for later reading. This helps organize reading interests in one place for convenient access. 
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:30}} community-submitted {{PLURAL:30|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the issue where infobox images have huge padding in Firefox, has been fixed. [https://phabricator.wikimedia.org/T423676]

'''Updates for technical contributors'''
* As a reminder, the global API rate limits will be applied this week to identified API traffic. This is to help ensure [[mw:MediaWiki Product Insights/Responsible Reuse|fair use of infrastructure]]. Bots running in Toolforge/WMCS or with the bot user right on any wiki should not be affected for now. However, all developers are advised to follow updated best practices. For more information, including the actual rate limits, see [[mw:Wikimedia APIs/Rate limits|Wikimedia APIs/Rate limits]] and [[mw:Wikimedia APIs/Rate limits/FAQ|Frequently Asked Questions]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.26|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/18|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W18&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 18:06, 27 April 2026 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30458046 --&gt;

== Wikipedia translation of the week: 2026-19 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Kuwait National Assembly Building]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Kuwait City Arabian Gulf Street 10.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Kuwait National Assembly Building''' is the building that housed the National Assembly of Kuwait.

Designed by Danish architect Jørn Utzon in 1972, it was completed in 1982 under the direction of his son Jan. The structural design was by Max Walt. The building was seriously damaged in February 1991 when retreating Iraqi troops set it on fire but has since been restored. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 12:16, 4 May 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30464799 --&gt;

== Tech News: 2026-19 ==

&lt;section begin=&quot;technews-2026-W19&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/19|Translations]] are available.

'''Weekly highlight'''
* The [[mw:Special:MyLanguage/Article guidance|Article guidance]] team invites experienced editors of [[mw:Special:MyLanguage/Article guidance/Pilot wikis and collaborators|pilot Wikipedias]]—Arabic, Bangla, Japanese, Portuguese, Persian, Turkish, Simple English, Spanish, and French—to help translate and adapt [https://b24e11a4f1.catalyst.wmcloud.org/wiki/Category:Pages_using_article_guidance sample outlines]. These outlines will guide editors in creating clear, well-structured, and policy-compliant articles when using [https://b24e11a4f1.catalyst.wmcloud.org/wiki/Special:NewArticle the feature] once it is launched in May 2026. [[mw:Special:MyLanguage/Article guidance#Adapting a sample outline in a Wikipedia|Simple instructions]] on how to translate and adapt the outlines are available.
'''Updates for editors'''
* The [[:m:Special:MyLanguage/Product and Technology Advisory Council|Product and Technology Advisory Council]] has published [[:m:Special:MyLanguage/Product and Technology Advisory Council/May 2026 draft PTAC recommendation for feedback|draft recommendations]] on a model that affiliates can follow when contributing to the technical space. Community members are invited to provide feedback on the recommendation until May 8th [[:m:Talk:Product and Technology Advisory Council/May 2026 draft PTAC recommendation for feedback|on the talk page]].
* The number of available thumbnail size preferences in MediaWiki is being reduced to three standardized options—Small (180px), Regular (250px), and Large (400px), as part of ongoing efforts to improve performance and reduce strain on thumbnail services. As a result, existing preferences will be mapped to the nearest new size (for example, smaller selections like 120px or 150px will render at 180px, while larger ones like 300px or 360px will render at 400px). The preferences interface will soon be updated to reflect these changes, and users who wish to opt out or provide feedback can do so. [https://phabricator.wikimedia.org/T424909]
* From now on, even when a permission expires automatically, users will receive an Echo notification similar to the standard notification for permission changes. There is a difference between this and [[m:Special:MyLanguage/Global reminder bot|Global reminder bot]] in that the latter reminds users a week ''before'' the rights are due to expire, so that they can renew the rights.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:32}} community-submitted {{PLURAL:32|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, the problem where the ULS language selector in [[m:Special:Translate|Special:Translate]] would scroll vertically when it shouldn't, has been resolved. Previously, when users opened the &quot;Translate to English&quot; dropdown and typed certain inputs, the dialog would scroll vertically by a few pixels even when there was enough space to display all results. The dropdown no longer shifts unnecessarily when filtering languages. [https://phabricator.wikimedia.org/T358864] 
* The [[m:Special:GlobalWatchlist|Global Watchlist]], which lets you view your watchlists from multiple wikis on a single page, continues to improve. For example, watchlists for Wikibase sites such as [[:d:|Wikidata]] now support [[mw:Special:MyLanguage/Extension:EntitySchema|EntitySchema]] elements for better tracking. The Live Updates mode now refreshes the special page every 60 seconds to comply with the updated [[mw:Special:MyLanguage/Wikimedia APIs/Rate limits|global API rate limits]] for improved real-time responsiveness. Additionally, a directionality bug that displayed links as &quot;changes 3&quot; instead of &quot;3 changes&quot; in mixed-direction lists has been fixed. [https://phabricator.wikimedia.org/T415450][https://phabricator.wikimedia.org/T424422][https://phabricator.wikimedia.org/T418091]
'''Updates for technical contributors'''
* The second phase of [[mw:Special:MyLanguage/Wikimedia APIs/Rate limits|global API rate limits]] has been rolled out to reduce the [[diffblog:2026/03/26/quo-vadis-crawlers-progress-and-whats-next-on-safeguarding-our-infrastructure/|impact of AI crawlers]] and ensure fair, sustainable access to Wikimedia resources, prioritising human and mission-aligned traffic. [[mw:Special:MyLanguage/Wikimedia APIs/Rate limits#Limits|Limits]] have been shifted from per-hour to per-minute, producing smoother traffic patterns and more predictable API load. Community users are not expected to be affected, and no action is required. Early indications show some User-Agent-based requestors are adjusting behaviour, and around 64% of automated API traffic has been identified. Monitoring continues, and Wikimedia Enterprise remains available for commercial support.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.46/wmf.27|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/19|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W19&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:44, 4 May 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30498077 --&gt;

== Wikipedia translation of the week: 2026-20 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Macau National Security Law]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Lei relative à defesa da segurança do Estado projecto.JPG|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Macau National Security Law''' is a law in Macau which prohibits and punishes acts of treason, secession, and subversion against the Central government, as well as preparative acts leading to any of the three acts. Taken into effect on 3 March 2009, the purpose of the law is to fulfil Article 23 of the Macau Basic Law, the de facto constitution of the Macau Special Administration Region. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:53, 11 May 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30513945 --&gt;

== Tech News: 2026-20 ==

&lt;section begin=&quot;technews-2026-W20&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/20|Translations]] are available.

'''Weekly highlight'''
* Community Tech has published [[m:Special:MyLanguage/Community Wishlist/How to write a good wish|new guidance]] explaining how wishes on Community Wishlist are triaged and prioritized. The documentation is intended to help contributors write stronger proposals by clarifying the factors that influence prioritization decisions. Beyond vote counts, the guidance highlights considerations such as potential impact on the community when determining which wishes move forward.

'''Updates for editors'''
* The Reader Growth team is launching an experiment to test a new [[mw:Special:MyLanguage/Readers/Reader_Growth/Share_Card|Share Card feature]] that allows readers to create visually engaging cards from Wikipedia articles or selected article sections and share them online, with each card linking back to the original article to help expand readership and article discovery. The mobile-only A/B test will be available to a portion of readers on Arabic, Chinese, French, Vietnamese, and English Wikipedia to better understand reading and sharing habits, and is scheduled to begin the week of May 18 and run for four weeks.
* The Android and iOS Wikipedia apps recently released the [[mw:Special:MyLanguage/Wikimedia_Apps/Team/25th_Birthday_Reading_Challenge|25-day reading challenge]] into Beta, as part of efforts to drive reader engagement by encouraging users to complete reading milestones. To track their reading streak during the challenge, App users can add a widget featuring Baby Globe to their home screen. The challenge officially begins May 11.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:17}} community-submitted {{PLURAL:17|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where the global preference for enabling syntax highlighting in wikitext could unexpectedly disable itself after being turned on, has now been fixed. [https://phabricator.wikimedia.org/T425286]

'''Updates for technical contributors'''
* [[File:Octicons-tools.svg|12px|link=|alt=|Advanced item]] The ResourceLoader module &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;mediawiki.ui.input&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;, deprecated since [[m:Special:MyLanguage/Tech/News/2023/39|September 2023]], will be removed this week. There is a [[mw:Special:MyLanguage/Codex/Migrating_from_MediaWiki_UI|guide for migrating from MediaWiki UI to Codex]] for any tools that use it. [https://phabricator.wikimedia.org/T420125]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.2|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/20|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W20&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:21, 11 May 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30524429 --&gt;

== Tech News: 2026-21 ==

&lt;section begin=&quot;technews-2026-W21&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/21|Translations]] are available.

'''Weekly highlight'''
* The Abstract Wikipedia team has identified five potential pilot wikis to assess their interest in adopting abstract articles on their wikis. The pilots are Malayalam, Bengali, Dagbani, Arabic, and Indonesian Wikipedia. The feedback period will be open until May 22. If your community is interested in becoming a pilot, [[m:Talk:Abstract Wikipedia|let us know on Meta]].

'''Updates for editors'''
* An experiment to show [[mw:Special:MyLanguage/Readers/Reader Experience/Reading lists|Reading Lists]] to logged-out readers on mobile web will launch on May 18 across German, Spanish, Italian, Portuguese, Polish, Dutch, Turkish, and Urdu Wikipedias, and will run for one month. The effort supports broader goals of helping readers save and organize articles for later reading, while encouraging habits that could lead to future Wikipedia contributions.
* To support a bookmark button in the Reading List beta feature, the &quot;Tools &gt; Action&quot; menu has been updated to display icons, including the watch star indicator that helps editors identify temporarily watched articles. The icons now also match those used on mobile, improving consistency across platforms. The change is currently limited to the actions menu and mainly affects editors with privileged user rights. [https://phabricator.wikimedia.org/T426008]
* [[mw:Special:MyLanguage/VisualEditor/Suggestion Mode|Suggestion Mode]] was released as an [[w:en:A/B test|A/B test]] for newcomer editors on the mobile website at [[phab:T421189|~15 Wikipedias]]. The experiment will measure the impact that Suggestion Mode has on the proportion of newcomer mobile web edit sessions that result in constructive (un-reverted) article edits. The experiment will also evaluate the feature's impact on editor retention, and monitor changes in revert and block rates.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue in the Wikipedia Android app where images could sometimes fail to load after opening a recommended reading list notification, has now been fixed. [https://phabricator.wikimedia.org/T418231]

'''Updates for technical contributors'''
* The [[mw:Special:MyLanguage/Wikidata Platform|Wikidata Platform team]] has published its [[d:Special:MyLanguage/Wikidata:SPARQL query service/WDQS backend update/Backend Replacement|backend replacement recommendation]] and accompanying [[wikitech:Wikidata Query Service/WDQS Architecture re-design|technical architecture]] for the migration of the Wikidata Query Service (WDQS) away from Blazegraph. Feedback is invited until May 25th 2026, especially on potential gaps and impacts on advanced use cases. Wikidata community members and WDQS users are also encouraged to help identify high-impact tools and workflows that may need attention on [[d:Wikidata:SPARQL query service/WDQS backend update/High-Impact Use Cases|this page]]. Feedback can be shared on the [[d:Wikidata talk:SPARQL query service/WDQS backend update|Migration talk page]] or during the [[d:Special:MyLanguage/Wikidata:Blazegraph Migration Office Hours|next office hour]]. See the [[d:Special:MyLanguage/Wikidata:Wikidata Platform team/Newsletter|WDP team newsletter]] for more details.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.3|MediaWiki]]

'''In depth'''

* On English, French, Japanese, and a few other Wikipedias, there was a [[diffblog:2025/09/02/better-detecting-bots-and-replacing-our-captcha/|trial of hCaptcha]], a third-party bot detection service. The trial showed that hCaptcha effectively detects and deters some bad-faith automated activity, on its own and by giving [[w:en:Wikipedia:Village pump (technical)/Archive 225#Introducing SuggestedInvestigations|checkusers and stewards]] signals to look into. Because the results were positive, hCaptcha will be rolled out across all wikis over the next few weeks. [[mw:Special:MyLanguage/Product Safety and Integrity/Anti-abuse signals/hCaptcha|See the hCaptcha project page]] for technical information about the implementation and privacy protections. [[diffblog:2026/05/04/better-detecting-bots-and-replacing-our-captcha-part-2/|Learn more]].
* The latest Community Tech update is now available, with progress across several Community Wishlist initiatives, including Reading Lists expansion from the mobile app to the website, new language support for &quot;Who Wrote That&quot; and the Personal Dashboard, improvements to 3D rendering and Charts, and upcoming work on talk page sorting, audio playback, and editing workflows. The update also shares current priorities, wishlist status trends, and opportunities for community feedback on future focus areas and the Wikimedia Foundation’s 2026–2027 Annual Plan. [[m:Special:MyLanguage/Community Wishlist/Updates#May 13, 2026: Latest updates from the Community Tech team|Read the full newsletter for details]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/21|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W21&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:22, 18 May 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30539262 --&gt;

== Wikipedia translation of the week: 2026-21 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Stela of the cactus bearer]]'''&lt;br /&gt; &lt;small&gt;''([[:es:Estela del portador del cactus]])&amp;#32;([[:ca:Estela del portador del cactus]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Estela Wachumero en Chavin.jpg|center|300px]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''stela of the cactus bearer''' is a monolith or stele of a single piece of granite, belonging to the Chavín culture of ancient Peru, which remains in its original location on the northwest side of the circular plaza at the archaeological site known as the ceremonial center of Chavín de Huántar in the Ancash region of Peru. It was discovered during the 1972 excavation season by Peruvian archaeologist Luis Guillermo Lumbreras. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 04:05, 21 May 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30529698 --&gt;

== Wikipedia translation of the week: 2026-22 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Griffith Hughes]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The Reverend '''Griffith Hughes''' (1707 – c.1758), FRS, was a Welsh naturalist, clergyman, and author. Hughes wrote The Natural History of Barbados, which included the first description of the grapefruit (also known as &quot;The Forbidden Fruit&quot;). His work was praised by Linnaeus, but it has also been considered a &quot;scientific fraud&quot;. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:32, 25 May 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30529698 --&gt;

== Tech News: 2026-22 ==

&lt;section begin=&quot;technews-2026-W22&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/22|Translations]] are available.

'''Weekly highlight'''
* Following a [[mw:Special:MyLanguage/Contributors/Account Creation Experiments#LOWM|successful account creation experiment]], an improved logged-out edit warning message will be deployed to all Wikimedia wikis in the first week of June. The change will only affect logged-out users on mobile web who open an editing session. The updated experience is designed to encourage account creation more clearly, while still allowing users to edit with temporary accounts. Results from the experiment showed a significant increase in account creation, with a 27% relative lift among users shown the updated message. As expected, as more people funnel into account creation, temporary accounts decreased by a relative 16%. The experiment did not show any significant changes in constructive edit rates or other monitored contributor metrics. [https://phabricator.wikimedia.org/T424595] 

'''Updates for editors'''
* For security reasons, members of certain user groups are [[m:Special:MyLanguage/Mandatory two-factor authentication for users with some extended rights|required to have two-factor authentication]] (2FA) enabled. Members of these groups will be unable to disable the last 2FA method on their account, and it will be impossible to add users without 2FA to these groups. Users will still be able to add new authentication methods or remove them, as long as at least one method is continuously enabled. In the next few weeks, users without 2FA will be removed from these groups. Notably, this applies to bureaucrats. See the linked tasks for deployment schedules. [https://phabricator.wikimedia.org/T423119][https://phabricator.wikimedia.org/T423120]
* [[m:Special:MyLanguage/WMDE Technical Wishes|WMDE Technical Wishes]] will run an [[w:en:A/B testing|A/B test]] on [[:phab:T415904|10 wikis]], testing [[m:WMDE Technical Wishes/References/Reference Previews|potential improvements for Reference Previews]]. The experiment will run for ~2 weeks at the end of May / beginning of June and will affect 10% of desktop readers on the participating wikis.
* After two successful experiments, the Reader Growth team is rolling out an [[mw:Special:MyLanguage/Readers/Reader Growth/Image Browsing|Image Browsing]] beta feature for all Wikipedias on mobile on May 25. This means that anyone who has all beta features on by default will start to see this feature, and others can check the box to turn it on in their preferences. The beta feature will include a carousel of all an article's images at the top of the article, with controls for editors to [[mw:Readers/Reader_Growth/Image_Browsing#Phase_2.1_beta_feature|exclude images from the article's carousel or to exclude an article from the feature entirely]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:30}} community-submitted {{PLURAL:30|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, three dimensional STL files were being rendered incorrectly by the media viewer 3D extension which is now fixed. [https://phabricator.wikimedia.org/T416723]

'''Updates for technical contributors'''
* The legacy CSS classes &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;tleft&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;tright&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; have been replaced with &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;floatleft&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;floatright&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; as the former do not work consistently across all MediaWiki platforms, notably mobile web and mobile apps. Projects relying on these classes are encouraged to review related usage and plan for migration. Please note that &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;floatleft&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;floatright&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; may also be deprecated in future, although there are currently no plans to do so. [[phab:T426452|Read more]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.4|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/22|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W22&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:52, 25 May 2026 (UTC)
&lt;!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30584502 --&gt;

== Wikipedia translation of the week: 2026-23 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Umuganda]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Umuganda&quot;Rwandan community work&quot;.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Umuganda''' is a national holiday in Rwanda taking place on the last Saturday of every month for mandatory nationwide community service from 08:00 to 11:00. Participation in Umuganda is required by law; failure to participate can result in a fine.

The program was most recently re-established under President Paul Kagame in 2009, having resulted in a notable improvement in the cleanliness of Rwanda. Also, there are other informal Umuganda day activities that occur in the middle of the month. These activities are initiated by either society or the government. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:55, 1 June 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30529698 --&gt;

== Tech News: 2026-23 ==

&lt;section begin=&quot;technews-2026-W23&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/23|Translations]] are available.

'''Updates for editors'''
* The [[mw:Special:MyLanguage/Readers/Reader Experience|Reader Experience team]] is conducting an experiment to show the [[mw:Special:MyLanguage/Readers/Reader Experience/Reading lists|reading lists]] feature, which is still in development, to logged-out mobile readers to test whether it encourages account creation at a higher rate compared to the watchstar button. The [[mw:Special:MyLanguage/Readers/Reader Experience/Reading lists#Experiment timeline|experiment]] was launched on May 18th on German, Spanish, Italian, Portuguese, Polish, Dutch, Turkish, and Urdu wikis, and it will run for a month.
* The Wikimedia Apps team released [[mw:Special:MyLanguage/Wikimedia Apps/Team/Explore Feed Refresh/Phase 1|Phase 1]] of the redesigned Home Feed to the Android Beta app. The new Home Feed includes a refreshed &quot;Community&quot; tab and a personalized &quot;For You&quot; tab featuring daily updated reading recommendations. The redesign is part of a broader effort to improve content discovery and create more engaging learning experiences in the Wikipedia apps.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:18}} community-submitted {{PLURAL:18|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where images could fail to load for some suggested edits on [[w:Special:Homepage|Special:Homepage]], leaving the thumbnail stuck in a loading state, has now been fixed. [https://phabricator.wikimedia.org/T424048]

'''Updates for technical contributors'''
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.5|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/23|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W23&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:09, 1 June 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30613639 --&gt;

== Wikipedia translation of the week: 2026-24 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Juryeonggu]]'''&lt;br /&gt; &lt;small&gt;''([[:kr:주령구]])&amp;#32;([[:ja:酒令具]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:주령구의 발굴 당시 사진.png|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
Il '''Juryeonggu''' (주령구?, 酒令具?, JuryeongguLR, ChuryŏngguMR) è un dado a 14 facce, risalente al periodo del Silla unificato (668-935 d.C.), ritrovato nel 1975 dopo alcuni scavi occorsi presso il Donggung e lo stagno Wolji di Gyeongju, in Corea del Sud. Le facce del dado mostravano inscrizioni recanti varie penalità o sfide, legate ad un gioco di bevute, dimostrando l'importanza dell'alcool e la raffinatezza con cui la sua assunzione veniva celebrata.

L'artefatto originale è andato perduto, incendiato in un maldestro tentativo di preservazione: oggi ne esistono delle repliche, disponibili anche commercialmente. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:20, 8 June 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30622359 --&gt;

== Tech News: 2026-24 ==

&lt;section begin=&quot;technews-2026-W24&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/24|Translations]] are available.

'''Weekly highlight'''
* Wikimedia Enterprise has increased the free usage limits for its API offerings. The monthly request limit for the On-demand API has increased from 5,000 to 50,000 requests, while the Snapshot API limit has increased from 15 to 30 requests per month. In addition, Structured Contents snapshots are now available for free accounts. These changes expand access to Wikimedia Enterprise data for developers, researchers, and organizations using Wikimedia content. [https://enterprise.wikimedia.com/blog/enhanced-free-api]

'''Updates for editors'''
* The [[mw:Special:MyLanguage/Wikimedia_Apps/Team/Explore Feed Refresh/Phase 1|refreshed Explore Feed]], now called the Home Feed, is rolling out to 50% of users of the Wikipedia Android app. The Home Feed helps readers discover relevant content through two new tabs: ''Community'' and ''For You''. The Community tab provides a scrollable feed of curated content and updates from the broader Wikimedia community and movement, while the ''For You'' tab offers a full-screen, swipeable experience that shows content tailored to a user's interests. The redesign is part of a broader effort to improve discovery and enhance the learning experience in the Wikipedia app.
* The [[mw:Special:MyLanguage/Wikimedia Apps/Team/iOS/&quot;Which came first?&quot; Game|Which came first?]] daily trivia game is now available in the beta version of the Wikipedia iOS app in English, German, French, Portuguese, Russian, Spanish, Arabic, Chinese, and Turkish. The game uses historical events from Wikipedia's &quot;On This Day&quot; content and challenges readers to guess which of two events happened first. The game was previously released on Android. Communities interested in making the game available in their languages can [[mw:Special:MyLanguage/Wikimedia_Apps/Team/Games#Game availability by language|read the instructions and requirements]].
* [[m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing|Sub-referencing]], a new MediaWiki feature that allows editors to reuse references with different details, will begin rolling out to Wikimedia wikis following a successful pilot phase. Deployment will start on 8 June for most [[wikitech:Deployments/Train#Wednesday|Group 1 wikis]] and French Wikipedia, with additional Wikipedia language editions receiving the feature over the coming months. Communities are encouraged to prepare by checking for [https://translatewiki.net/w/i.php?title=Special%3ATranslate&amp;group=ext-cite&amp;language=en&amp;action_source=search&amp;filter=%21translated&amp;optional=1&amp;action=translate untranslated Cite extension messages] in their language and reviewing any use of [[mw:Special:MyLanguage/Reference Tooltips|Reference Tooltips]], which may require [[:phab:T416304#11668731|updates]] to support the new functionality. Wikis using [[mw:Special:MyLanguage/Help:Reference Previews|Reference Previews]] do not need to take any action. Communities may also wish to create the ''cite-tracking-category-ref-details'' [[Special:TrackingCategories|tracking category]] as a hidden category using &lt;code&gt;&lt;nowiki&gt;__HIDDENCAT__&lt;/nowiki&gt;&lt;/code&gt; (or a dedicated template), and connect it to the corresponding Wikidata item [[d:Q129764848]]. [https://phabricator.wikimedia.org/T425662]
* The [[mw:Special:MyLanguage/Readers/Reader Growth/Mobile page previews#Experimentation|Page Previews experiment]] on mobile web has concluded. The team decided not to roll out the feature after the results showed no statistically significant impact on reader retention, as the primary success metric was retention improvement. Page Previews, which are already available on desktop and in the apps, display a thumbnail, lead paragraph, and link to the full article when readers tap a blue link. The experiment tested this experience on mobile web across six Wikipedias.
* The [[mw:Special:MyLanguage/Codex/Design/Icons|user interface icon library]] will be [[phab:T399175|updated later this week or next week]]. Most of the ~300 icons have been slightly refined and ~30 new icons have been added. These changes improve the icons to make them more consistent and comprehensible, and provide more visual balance when they are used in groups.
* The [[mw:Special:MyLanguage/Universal Language Selector|Universal Language Selector]] (ULS) interface in MediaWiki, which helps users select content in other languages, has been updated. The new version improves speed and accessibility, and users of Wikimedia projects can now pin languages for quicker language switching. The deployment to Wikimedia sites will happen gradually in the coming weeks. You can test it now as a beta feature by selecting [[Special:Preferences#mw-prefsection-betafeatures|beta features]] in your profile preferences and share your feedback on [[mw:Special:MyLanguage/Universal Language Selector/New ULS|the project page]]. 
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:21}} community-submitted {{PLURAL:21|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where the Pageviews Analysis dashboard on pageviews.wmcloud.org stopped updating graph data in May 2026, affecting all users, has been fixed. [https://phabricator.wikimedia.org/T427171]

'''Updates for technical contributors'''
* The function signature for &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;mw.util.addPortletLink()&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; has been simplified. Developers can now pass a configuration object instead of a list of positional parameters when creating portlet links. The previous function signature remains supported for backwards compatibility. For example, instead of: &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;mw.util.addPortletLink('p-cactions', '#', 'Stub', 'ca-stubtag', 'Add a stub tag to this page');&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; use &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;mw.util.addPortletLink('p-cactions', { href: '#', text: 'Stub', id: 'ca-stubtag', tooltip: 'Add a stub tag to this page' });&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;. Script maintainers are encouraged to review existing uses of &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;addPortletLink()&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; and update them where appropriate. This change will be available on all wikis from 11 June. Thanks to community volunteer Gerges for contributing this improvement. [https://phabricator.wikimedia.org/T427945]
* '''Community Wishlist discussion''': Product &amp; Technology [[m:Special:MyLanguage/Community Wishlist/Updates#May 20, 2026: Community Tech becomes a program|introduced changes]] meant to increase the number and complexity of wishes fulfilled, including the disbanding of the Community Tech team. They are [[m:Special:MyLanguage/Community Wishlist/Updates|engaging in discussions]] about a [[m:Talk:Community Wishlist#Proposed direction for Wishlist|proposed direction for the wishlist]] from community members. Includes ways to structure annual voting, better tracking of wishes, removing focus areas, and [[m:Special:MyLanguage/Community Wishlist/Updates|staffing updates]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.6|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/24|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W24&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 21:30, 8 June 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30650573 --&gt;

== Wikipedia translation of the week: 2026-25 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Cape Fiolent]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Beach of Cape Fiolent, Crimea.jpg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Cape Fiolent''' (Crimean Tatar: Felenk Burun; Ukrainian: Фіолент; Russian: Фиолент; Latin: Parthenium), also historically called Cape Fiolente, is a cape and nature reserve (zakaznik) located in southern Sevastopol, a city within Crimea that is internationally recognised as part of Ukraine but currently occupied by Russia since 2014. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:24, 15 June 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30662919 --&gt;

== Tech News: 2026-25 ==

&lt;section begin=&quot;technews-2026-W25&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/25|Translations]] are available.

'''Weekly highlight'''
* The [[mw:Special:MyLanguage/Readers/Reader Growth|Reader Growth team]] has launched an [[mw:Special:MyLanguage/Readers/Reader Growth/Image Browsing|Image Browsing]] beta feature on the mobile web version of all Wikipedias. The feature shows an image carousel at the top of articles with 3 or more images. Editors can configure this feature with the following controls: to hide a specific image from a page, either use &lt;code&gt;class=notpageimage&lt;/code&gt; excluding it from thumbnail previews, or &lt;code&gt;class=noviewer&lt;/code&gt; excluding it from MediaViewer. The carousel can also be disabled from a page entirely, with the magic word &lt;code&gt;&lt;nowiki&gt;__NOMEDIAVIEWERCAROUSEL__&lt;/nowiki&gt;&lt;/code&gt;. To submit feedback or flag bugs, please visit the [[mw:Talk:Readers/Reader Growth/Image Browsing|project page]]. 
* [[mw:Special:MyLanguage/Help:Tables#class=&quot;wikitable&quot;|Wikitables]] can now be [[mw:Special:MyLanguage/Help:Sortable tables#Forcing the initial sort direction|sorted in descending order]] on the first click by adding &lt;code dir=ltr&gt;data-sort-order=&quot;desc&quot;&lt;/code&gt; to the header cell. Previously, by default, clicking a column header for the first time sorts it in ascending order. This addition to a Wikitable gives it more control and flexibility, while the default behavior for subsequent clicks remains unchanged. [https://phabricator.wikimedia.org/T398416]

'''Updates for editors'''
* The [[mw:Special:MyLanguage/Article guidance|Article guidance]] feature is currently being tested with some editors creating new articles on the Simple English, French, and Turkish Wikipedias. The experiment will soon begin on the Arabic and Bangla Wikipedias as well. [[w:simple:Special:NewArticle|This feature]] gives editors community-curated guidance to help them create articles that follow community standards. Experienced editors can continue creating or adapting outlines for specific article types that are commonly created by less experienced contributors. The outlines guide less experienced editors in creating high-quality articles. A quick guide to markups used in outlines can be found on [[mw:Special:MyLanguage/Article guidance/Test feature guide#Markups in outlines|this page]]. [[w:simple:Wikipedia:Article Guidance|Example outlines]] that can be adapted and instructions for how to adapt them are on [[mw:Special:MyLanguage/Article guidance#Adapting a sample outline in a Wikipedia|this section]] of the project page.
* Wikis that wish to replace the &quot;indefinitely&quot; button in Special:Block for temporary accounts (for example, wikis that block temporary users only until account expiration) will be able to do so by creating [[MediaWiki:ipb-indefinite-expiry-temporary-account]] with the block duration they want. [https://phabricator.wikimedia.org/T427125]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:41}} community-submitted {{PLURAL:41|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* By the end of June, a valid user-agent string will be required for automated dumps downloads from the dumps.wikimedia.org website. Automated requests that provide a generic or empty user-agent will be blocked. This [[phab:T400119|extends enforcement]] of the long standing [[foundation:Special:MyLanguage/Policy:Wikimedia Foundation User-Agent Policy|user-agent policy]]. Access to dumps through Wikimedia Cloud Services will not change.
* The roll out of global [[mw:Wikimedia APIs/Rate limits|API rate limits]] is now complete, with limits enforced across all APIs and at the documented levels for all groups. Bots running in Toolforge/WMCS or with the bot user right on any wiki remain exempt. All bots should continue to follow the documented best practices to avoid being rate limited.
* The [https://api.wikimedia.org/wiki/Main_Page API Portal wiki] will be read only starting this week (June 15-18). The following week (June 22-25), all API Portal wiki URLs will redirect to [[mw:Wikimedia APIs|Wikimedia APIs on mediawiki.org]]. Learn more on the [[wikitech:API Portal/Deprecation|project page]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.7|MediaWiki]]

'''Meetings and events'''
* On June 17th at 6pm UTC the WMF will be holding Discord call focused on a code review. We've heard through the [[mw:Special:MyLanguage/Developer Satisfaction Survey/2026|Developer Satisfaction Survey]] that volunteers are struggling with code review and we'd like to discuss these experiences with the goal of surfacing workable solutions. You can join the call [https://discord.gg/wikipedia?event=1514727511102062664 via the Wikimedia Community Discord server].
* The [[m:Special:MyLanguage/Conferencia Wikimedia de América Latina 2026|Latin American Wikimedia Conference]] will host a regional hackathon that will bring together the Wikimedia movement’s technical community including developers, system administrators, data scientists, and users with extended rights. Interested technical contributors can [https://docs.google.com/forms/d/e/1FAIpQLSf4osJzTHBJjQbYJk7TMVEJjTEQv7IgtsUDfP-o-qTgeRQQxw/viewform apply for a scholarship] to participate until June 21 at midnight (Bolivia time, UTC-4).
* Sign up for Wikimania Team Challenges to join this special event. The Team challenges will take place online and in person from July 21 to 22, before Wikimania conference. Everyone is welcome, regardless of skills or Wikimania registration. Teams will work on 10 important challenges supporting the Wikimedia community. For details, visit [[wmania:Special:MyLanguage/2026:Team challenges|the Team Challenges page]] and [https://wikimedia.eventyay.com/wm/teamchallenges/ register there]. Registration closes on June 20th at 11pm UTC. 

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/25|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W25&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 16:49, 15 June 2026 (UTC)
&lt;!-- Message sent by User:UOzurumba (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30689604 --&gt;

== Wikipedia translation of the week: 2026-26 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Renovating Action Party]]'''&lt;br /&gt; &lt;small&gt;''([[:es:Partido de Acción Renovadora]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Flag of the Renovating Action Party.svg|300px|center]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Renovating Action Party''' was a left-wing Salvadoran political party that existed from 1944 to 1967. The party had three distinct phases of its existence under the leaderships of Colonel José Asencio Menéndez (1944–1950), the old line (1950–1964), and the new line (1964–1967). 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:52, 22 June 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30717601 --&gt;

== Tech News: 2026-26 ==

&lt;section begin=&quot;technews-2026-W26&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/26|Translations]] are available.

'''Weekly highlight'''
* [[mw:Special:MyLanguage/Growth/Feature summary|Growth features]] are [[phab:T418115|now available at Wikidata]]. This update enables access to Mentorship ([[mw:Special:MyLanguage/Help:Growth/Mentorship|if configured]]), Impact module, the Help Panel, and a simplified Newcomer Homepage (without Suggested Edits). Wikidata administrators are still configuring the features through Community Configuration.

'''Updates for editors'''
* The special page [[{{#special:RangeCalculator}}]] has been created. It allows users to find an IP range without needing to rely on external tools. Until now, this tool was only available to CheckUsers. [https://phabricator.wikimedia.org/T268429]
* [[m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing|Sub-referencing]] is a new MediaWiki feature that allows editors to reuse references with different details. It will be deployed to most small and medium-sized Wikipedia language versions on June 23. The [[m:Special:MyLanguage/WMDE Technical Wishes/Sub-referencing#deployment|FAQ]] lists possible actions to take on your wiki to support the deployment. Check the [[:phab:T414094|rollout plan]] for the next deployment steps. [https://phabricator.wikimedia.org/T428902]
* Starting next week, users will get a notification when they are blocked or unblocked from editing, or if this block changes. [https://phabricator.wikimedia.org/T100974]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:32}} community-submitted {{PLURAL:32|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]].

'''Updates for technical contributors'''
* Starting next week, abuse filters that are set to &quot;require CAPTCHA verification&quot; will begin to also affect users with the &lt;code&gt;skipcaptcha&lt;/code&gt; right, which includes most autoconfirmed users. Bots are exempted. This change only affects edits that trigger an abuse filter. The &lt;code&gt;skipcaptcha&lt;/code&gt; right will continue to exempt users from having to solve CAPTCHAs in the ordinary course of using the wikis. [https://phabricator.wikimedia.org/T402595]
* Reference documentation for the [[wikitech:Machine_Learning/LiftWing/API|Lift Wing API]] has moved from the API Portal to the interactive [https://wikitech.wikimedia.org/w/index.php?api=lift-wing&amp;title=Special%3ARestSandbox REST Sandbox].
* The API Portal wiki is now closed. For API documentation, see [[mw:Special:MyLanguage/Wikimedia_APIs|Wikimedia APIs on mediawiki.org]]. All API Portal wiki URLs (https://api.wikimedia.org/wiki/) will redirect to the mediawiki.org page starting June 22. [https://phabricator.wikimedia.org/T427537]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.8|MediaWiki]]

'''Meetings and events'''
* Join an online call on 25 June at 2:30pm UTC to meet the current Wikimedia interns for [[mw:Google_Summer_of_Code/2026|Google Summer of Code]] and [[mw:Outreachy/Round_32|Outreachy]]. Interns will provide an overview of their projects and a brief demo of their work so far. Attendees are encouraged to [[mw:event:Google_Summer_of_Code/Summer_2026_June_Internship_open_session|share ideas and connections in their community]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/26|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W26&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 13:05, 23 June 2026 (UTC)
&lt;!-- Message sent by User:Trizek (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30722494 --&gt;

== Wikipedia translation of the week: 2026-27 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Facial age estimation]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Facial age estimation''' is the use of artificial intelligence to estimate the age of a person based on their facial features. Computer vision techniques are used to analyse the facial features in the images of millions of people whose age is known and then deep learning is used to create an algorithm that tries to predict the age of an unknown person. The key use of the technology is to prevent access to age-restricted goods and services. Examples include restricting children from accessing internet pornography, checking that they meet a mandatory minimum age when registering for an account on social media, or preventing adults from accessing websites, online chat or games designed only for use by children. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 00:44, 29 June 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30717601 --&gt;

== Tech News: 2026-27 ==

&lt;section begin=&quot;technews-2026-W27&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/27|Translations]] are available.

'''Updates for editors'''
* As part of the [[mw:Special:MyLanguage/Contributors/Account Creation Experiments|Account Creation Experiments]], the Growth team tested adding a user account icon in the mobile web header for logged-out users, providing direct access to &quot;Create account&quot; and &quot;Log in&quot; actions. The experiment increased account creation by about 20% without negatively affecting edit quality or constructive edit rates. The feature will now be rolled out to all Wikimedia Foundation wikis on mobile web in the first week of July. [https://phabricator.wikimedia.org/T428220]
* After a [[phab:T426248|successful experiment]], logged-in users who did not [[mw:Special:MyLanguage/Help:Email_confirmation|confirm their email address]] when their account was created see a new banner asking them to complete that process. This helps reduce the risk that users get locked out of their account, and makes account email addresses overall more reliable. This is part of the [[mw:Special:MyLanguage/Product Safety and Integrity/Account Security|Account Security]] project. [https://phabricator.wikimedia.org/T428292]
* An update to [[Special:Search|Search]] is refining how the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;-prefix:&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; behaves when used to exclude results. Previously, using &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;-prefix:&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; with negation could unintentionally broaden search results by adding the namespaces included in the search scope, leading to confusing behavior for users expecting a straightforward exclusion filter. With the update, &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;-prefix:&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; will now strictly exclude matching page titles as intended and may display a warning if the relevant namespace has not been explicitly selected. The behavior of &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;prefix:&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; without negation however remains unchanged. [https://phabricator.wikimedia.org/T427443]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:33}} community-submitted {{PLURAL:33|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where reviewers using the Page Curation toolbar were not automatically subscribed to talk page discussions they started has now been fixed. Reviewers will now receive notifications when someone replies to those discussions. [https://phabricator.wikimedia.org/T329346]

'''Updates for technical contributors'''
* Starting June 29th, automated downloads from the dumps.wikimedia.org website will be subject to the [[Foundation:Special:MyLanguage/Policy:Wikimedia Foundation User-Agent Policy|user-agent policy]]. Automated requests that provide a generic or empty user-agent will be blocked. Access to dumps through Wikimedia Cloud Services remains unaffected. This is a follow up to the announcement made in the [[m:Special:MyLanguage/Tech/News/2026/25|2026/25 issue of Tech News]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.9|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/27|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W27&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 11:48, 29 June 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30744833 --&gt;

== Wikipedia translation of the week: 2026-28 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Paulo César Vinha State Park]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Capim dourado.jpg|300px|center|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''Paulo César Vinha State Park''' (Portuguese: Parque Estadual Paulo César Vinha) is a state park in the state of Espírito Santo, Brazil. It protects an area of dunes, lagoons and marshes along the Atlantic shore. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:35, 6 July 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30717601 --&gt;

== Tech News: 2026-28 ==

&lt;section begin=&quot;technews-2026-W28&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/28|Translations]] are available.

'''Updates for editors'''
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:34}} community-submitted {{PLURAL:34|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where the search bar results on Wikidata, showed English results instead of using the correct language fallback for users of language variants, has now been fixed. Search suggestions will now follow the expected language fallback chain. [https://phabricator.wikimedia.org/T429769]

'''Updates for technical contributors'''
* In preparation for [[m:Special:MyLanguage/Event:Celebrate Women|Celebrate Women campaign]] planned for March 2027, the Wikimedia Foundation’s [[m:Special:MyLanguage/Wikimedia Foundation/Advancement/Community Growth/Content Enablement|Content Enablement team]] has launched a 22-question survey to better understand technical contributions by women+ (anyone who identifies as a woman) across Wikimedia projects. The survey takes approximately 15–20 minutes to complete and will remain open until 20 July 2026. The [[m:Special:MyLanguage/Celebrate Women/Technical contributions survey|questions]] are also available on-wiki for review in advance.
* The [[mw:Special:MyLanguage/Extension:Score|Score extension]] now supports rendering music scores as SVG images in addition to PNG, addressing a long-standing [[:phab:T49578|feature request]] and resolving historical image quality issues. Both formats are now provided to clients, with PNG in the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;src&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; attribute and SVG in the &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;srcset&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; attribute.
* The new [[wikitech:Parsoid|Parsoid]] parser [[mw:Special:MyLanguage/Parsoid/Parser_Unification/Updates|continues to be deployed to additional wikis]], making it easier to introduce new reading and editing features. It was enabled on French Wikipedia, bringing total progress to covering 78.9% of Wikipedia page views. Rollout to English Wikipedia desktop will progress through this week.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.10|MediaWiki]]

'''In depth'''
* The Wikimedia Hackathon 2026 [[diffblog:2026/06/29/wikimedia-hackathon-2026-building-collaborating-and-shaping-the-future-together/|recap blog post]] is now live. It highlights the projects, sessions, and social activities from this year’s event, and shares initial plans for the 2027 Wikimedia Hackathon.

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/28|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W28&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 13:57, 6 July 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30773578 --&gt;

== Wikipedia translation of the week: 2026-29 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Caledonian MacBrayne]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Cal-Mac HQ2005.jpg|300px|center|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Caledonian MacBrayne''', in short form CalMac, is the trade name of CalMac Ferries Ltd, the major operator of passenger and vehicle ferries to the west coast of Scotland, serving ports on the mainland and 22 of the major islands. It is a subsidiary of holding company David MacBrayne, which is owned by the Scottish Government. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
-[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 01:20, 13 July 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30717601 --&gt;

== Tech News: 2026-29 ==

&lt;section begin=&quot;technews-2026-W29&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/29|Translations]] are available.

'''Updates for editors'''
* [[mw:Special:MyLanguage/Growth/Revise_Tone|Revise Tone]] helps newcomers identify passages in Wikipedia articles that may contain non-encyclopedic language and encourages them to consider revising the tone. The feature was [[w:en:A/B_testing|A/B tested]] on the Arabic, English, French, and Portuguese Wikipedias, where newcomer task completion rates [[mw:Special:MyLanguage/Growth/Revise_Tone#Experiment_Results|increased by 38.7%]] compared to the default Copyedit task, with no decrease in edit quality. The test ended on July 9, and the feature is now available for everyone on these wikis, configurable via Community Configuration. [[phab:T426364|The plan]] is to release Revise Tone to more wikis.
* The community configuration that allows [[mw:Special:MyLanguage/Help:Growth/Mentorship#Automated mentor list cleanup|automatic removal of inactive mentors]] based on configurable criteria will be enabled on Thursday 16, [[mw:Special:MyLanguage/Growth/Deployment|on some wikis]] to keep mentor lists up to date. Mentors are experienced contributors who opt in to help new users on-wiki through the [[mw:Special:MyLanguage/Growth/Feature summary|Growth Features]]. Administrators can now prepare the settings via [[w:Special:CommunityConfiguration/Mentorship|Special:CommunityConfiguration/Mentorship]]; they will take effect starting Thursday.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:38}} community-submitted {{PLURAL:38|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where some users of the Wikipedia Android app were logged out immediately after signing in, preventing them from staying logged in and editing pages, has now been fixed. [https://phabricator.wikimedia.org/T316916]

'''Updates for technical contributors'''
* Editing a page via user scripts or gadgets was causing watchlist labels that the user had assigned to that page to reset. This has now been fixed. [https://phabricator.wikimedia.org/T423778]
* To work around a Safari bug (see [[phab:T425211]]), on Parsoid-enabled wikis, wikilink hrefs now use absolute urls instead of protocol-relative urls. REST API output remains unchanged and continue to use protocol-relative urls. Gadgets, user scripts, bots, and CSS might need to be adapted if they relied on the presence of protocol-relative urls in wikilink hrefs. [https://phabricator.wikimedia.org/T431358]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.11|MediaWiki]]

'''In depth'''
* The Wikimedia Foundation’s Experiment Platform Team has published a blog post reflecting on its first year of structured experimentation. It highlights successful experiments such as Paste Check, Reference Check, and Tone Check, which improved editing outcomes and have been rolled out to more users, as well as experiments that did not lead to product changes. [[diffblog:2026/07/07/moving-the-needle-how-we-test-new-ideas-across-wikimedia-projects|Read more]].

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/29|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W29&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 16:12, 13 July 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30804401 --&gt;

== Wikipedia translation of the week: 2026-30 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Immigration to Switzerland]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
In 2023, resident foreigners made up 26.3% of Switzerland's population. Most of these (83%) were from European countries. Italy provided the largest single group of foreigners, accounting for 14.7% of total foreign population, followed closely by Germany (14.0%), Portugal (11.7%), France (6.6%), Kosovo (5.1%), Spain (3.9%), Turkey (3.1%), North Macedonia (3.1%), Serbia (2.8%), Austria (2.0%), United Kingdom (1.9%), Bosnia and Herzegovina (1.3%) and Croatia (1.3%). Immigrants from Sri Lanka (1.3%), most of them former Tamil refugees, were the largest group of Asian origin (7.9%).  

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:18, 20 July 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30717601 --&gt;

== Tech News: 2026-30 ==

&lt;section begin=&quot;technews-2026-W30&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/30|Translations]] are available.

'''Updates for editors'''
* The [[mw:Special:MyLanguage/Reader/Reader Experience|Reader Experience team]] has incorporated community feedback around the placement of watchstar and watchlist buttons for the [[mw:Special:MyLanguage/Readers/Reader Experience/WE3.3.4 Reading lists|Reading Lists beta feature]], which would allow for saving articles for later reading – a [[m:Special:MyLanguage/Community Wishlist/W102|wishlist item]] to bring the functionality to web. Editors are invited to enable the beta feature to test it out and [[phab:T426453|share their thoughts]].
* [[mw:Special:MyLanguage/VisualEditor/Suggestion Mode|Suggestion Mode]] offers edit suggestions within the VisualEditor for improving Wikipedia articles. [[Special:EditChecks|All suggestions]] are [[mw:Special:MyLanguage/Help:Suggestion mode#For administrators – local customization|community-configurable]]. The [[mw:Special:MyLanguage/Edit check/TextMatch|TextMatch]] feature is a way for volunteers to create custom local suggestions. The feature searches in articles for strings of text, and now includes support for regular expressions. This gives volunteers greater precision and flexibility over the kinds of local suggestions they can create. Note: Suggestions [[mw:Special:MyLanguage/Edit check/Configuration#:~:text=maximumEditcount|can be targeted]] based on the edit count of the person editing as well as other aspects of the page. You can [[mw:Special:MyLanguage/Help:Suggestion mode#Create custom local types of Suggestions|find examples from other communities]] for inspiration, including TextMatches that detect: typos, grammar-errors, potential advertisements, clichés, incorrect dash or hyphen usage, non-specific time keywords, outdated names, and more. Any [[mw:Special:MyLanguage/Talk:VisualEditor/Suggestion Mode|feedback]] is appreciated.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:27}} community-submitted {{PLURAL:27|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where the SVG Translate tool could use an outdated version of a file, causing existing translations to be overwritten when new ones were uploaded, has now [[phab:T430577|been fixed]]. Overall, in the last quarter from April – June 2026 about 337 community tasks were resolved by the Wikimedia Foundation.

'''Updates for technical contributors'''
* On Parsoid-enabled wikis, Parsoid now renders a maximum of 1,250 images per page. A new tracking category, &quot;media-limit-reached&quot;, will be soon made available to identify pages where this limit is reached, making it easier to find content whose media output may have been restricted during rendering. See [[phab:T430854]] for more information and to provide feedback.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.12|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/30|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W30&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 05:47, 21 July 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30836091 --&gt;

== Wikipedia translation of the week: 2026-31 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:fr:Study of Man's Impact on Climate]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
La '''Study of Man's Impact on Climate''' (traduisible en français par « Étude de l'impact de l'homme sur le climat ») est une conférence scientifique internationale consacrée à l'influence humaine sur le climat qui s'est tenue à Stockholm, en Suède, du 28 juin au 16 juillet 1971. Elle aborde diverses hypothèses parmi lesquelles la destruction de la couche d'ozone et le réchauffement (ou refroidissement) climatique, établit l'état du savoir à leur sujet et, soulignant les nombreuses inconnues qui demeurent, appelle à consacrer davantage de fonds à la recherche scientifique sur le climat. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:00, 27 July 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30849684 --&gt;

== Tech News: 2026-31 ==

&lt;section begin=&quot;technews-2026-W31&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/31|Translations]] are available.

'''Updates for editors'''
* [[File:Maki-gift-15.svg|12px|link=|class=skin-invert|Wishlist item]] [[mw:Special:MyLanguage/ContentTranslation|Content Translation]] now supports dark mode, fulfilling a [[m:Community Wishlist/W544|Community Wishlist request]]. This brings the tool in line with the accessibility features available in the Vector 2022 and Minerva skins, helping reduce visual fatigue for users translating content. [https://phabricator.wikimedia.org/T367077]
* DiscussionTools' source mode and the 2017 wikitext editor will now offer autocomplete for links (&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;[[&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;), templates (&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;{{&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;), HTML and parser tags (&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;&lt;&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;), and magic words (&lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;__&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;), making it quicker and easier to insert links, templates, and other wiki markup while editing. [https://phabricator.wikimedia.org/T432400]
* The [[mw:Special:MyLanguage/Readers/Reader Growth/Mobile page previews|Readers Growth team]] has concluded its experiment with mobile page previews and will not roll out the feature. Page Previews are a pop-up bottom sheet that appears when readers tap a blue link, showing a thumbnail, lead paragraph, and an option to open the article. The experiment showed flat retention and negative indicator metrics, suggesting that mobile web readers preferred navigating directly to linked articles rather than using page previews.
* The Reader Experience team has seen encouraging early results from the [[mw:Special:MyLanguage/Readers/Reader Experience/Reading lists|Reading Lists feature]], with 93% of participating users reporting that it was useful. Reading Lists help active readers save articles for future reading and support their learning goals on Wikimedia projects. The team plans further improvements before expanding the feature to more users.
* The [[mw:Special:MyLanguage/Wikimedia Apps/Team/Explore Feed Refresh|Explore Feed Refresh]] initiative was tested with new and casual Wikipedia app readers. The refreshed feed helps readers discover new and relevant content. After a 10.5% increase in engagement with the feed, Wikimedia Apps team has decided to scale the Home Feed redesign to iOS with the learnings from the Android release applied.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:23}} community-submitted {{PLURAL:23|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where subject names in the Article Guidance feature were displayed with incorrect capitalization on French Wikipedia, has now been fixed. Subject names will now follow the correct capitalization rules for the language. [https://phabricator.wikimedia.org/T427201]

'''Updates for technical contributors'''
* After running several [[mw:Special:MyLanguage/Contributors/Account Creation Experiments|Account Creation Experiments]] to improve registration completion rates, a new version of the username field on [[Special:CreateAccount|Create Account]] has been rolled out. It includes [[:c:File:Create account - July 2026 updates.png|a popover summarizing the username policy]] to provide clearer guidance during account creation. As part of this change, the messages &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;createacct-helpusername&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;createacct-username-help&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; that several communities have configured will no longer be used. If communities want to customize the guidance shown in the new popover, they can instead edit the following messages: &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;createacct-username-policy-popover-bullet1&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;, &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;createacct-username-policy-popover-bullet2&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;, and &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;createacct-username-policy-popover-bullet3&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt;. [https://phabricator.wikimedia.org/T430604]
* Later this week, the [[mw:Special:MyLanguage/Help:Extension:CodeMirror|CodeMirror syntax highlighter]] will offer [[w:en:Theme (computing)|themes]]. The themes can be picked from a dropdown menu in the full [[mw:Special:MyLanguage/Help:Extension:CodeMirror#CodeMirror preferences|CodeMirror preferences]] dialog. For wikitext, available themes are default, colorblind-friendly (previously the colorblind preference option on [[Special:Preferences#mw-prefsection-editing]]) and no-highlighting. For code languages (i.e., CSS/JavaScript/JSON/Vue/Lua), there are several themes available. These same themes will eventually be available for wikitext, too. [https://phabricator.wikimedia.org/T163533]
* From now on, wikis can restrict editing in the &quot;User&quot; namespace to only the page owner and certain user groups. [[mw:Special:MyLanguage/Manual:$wgRestrictUserPageEditing|Read the configuration documentation]] to learn more.
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.14|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/31|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W31&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 18:50, 27 July 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30856308 --&gt;

== Wikipedia translation of the week: 2026-32 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:en:Plot of Prats de Molló]]'''&lt;br /&gt; &lt;small&gt;''([[:ca:Fets de Prats de Molló]])&amp;#32;([[:es:Complot de Prats de Molló]])''&lt;/small&gt; &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----

&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
The '''plot of Prats de Molló''' was an attempted military invasion of Catalonia carried out from France to achieve its independence planned by Francesc Macià and the leadership of the Estat Català party, discovered and aborted in 1926. The plan consisted of the penetration of two columns (one from Saint-Laurent-de-Cerdans, the other from Coll d'Ares), which were to occupy Olot and proclaim the Catalan Republic. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 03:11, 3 August 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30879613 --&gt;

== Tech News: 2026-32 ==

&lt;section begin=&quot;technews-2026-W32&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/32|Translations]] are available.

'''Updates for editors'''
* The [[mw:Special:MyLanguage/Readers/Reader Experience|Reader Experience team]] has developed a [https://82db7c8d4b.catalyst.wmcloud.org/w/index.php?title=Regent%27s_Park&amp;uselang=de patch demo] that wraps the page toolbar onto two lines when there is not enough horizontal space for all the buttons. This aims to reduce crowding in the Vector 2022 toolbar, which can occur on some language Wikipedias at certain screen widths. [https://phabricator.wikimedia.org/T429518]
* The Reader Experience team is planning to launch [[mw:Special:MyLanguage/Readers/Reader Experience/Reading lists|Reading Lists]], a [[m:Special:MyLanguage/Community Wishlist Survey 2021/Mobile and apps/Have Apps reading lists available on Destop/Mobile|Community Wishlist item]], which is currently available to try in beta, as a full feature in September. Before then, volunteer translator help is needed for [https://translatewiki.net/w/i.php?title=Special%3ATranslate&amp;group=ext-readinglists&amp;filter=&amp;action=translate string translations] into a number of languages. The feature supports reading and learning goals on Wikipedia.
* Next week, the table of contents on Wikimedia Commons file pages will be improved by consolidating the file page table of contents with the page table of contents. This will make it easier to understand a file page’s structure, navigate to specific sections, and share links to individual sections. [https://phabricator.wikimedia.org/T332644]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:24}} community-submitted {{PLURAL:24|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where some [[w:TIFF|TIFF]] images failed to load after clicking their thumbnail, causing a broken image to be displayed instead of the full-size image, has now been fixed. [https://phabricator.wikimedia.org/T429326]

'''Updates for technical contributors'''
* The variable and function selector in AbuseFilter has been updated to support search and autocomplete. It will allow filter maintainers to find the desired variable or function more quickly. [https://phabricator.wikimedia.org/T323698]
* The MJPEG and VP8 formats are removed from the video player. The MP4 format (MPEG-4 Part 2) is added instead, which provides higher quality videos to older iPhone devices. It may take a few weeks to retroactively update all existing videos. The default format for modern devices stays the same (VP9/WebM). [https://phabricator.wikimedia.org/T358266]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.15|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/32|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W32&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 19:47, 3 August 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30872536 --&gt;

== Wikipedia translation of the week: 2026-33 ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; style=&quot;width:100%; margin:0; background: var(--background-color-neutral-subtle,#f8f9fa); border:1px solid var(--border-color-base,#BBBBBB); padding .4em;color: inherit;&quot;&gt;
&lt;div style=&quot;text-align:center;&quot;&gt;The winner this [[m:Translation of the week/2026 translations|Translation of the week]] is

&lt;div style=&quot;font-size:140%;&quot;&gt;'''[[:it:Composizione VII]]'''&lt;br /&gt;  &lt;/div&gt;
Please be bold and help translate this article!
&lt;/div&gt;
----
[[File:Composition VII - Wassily Kandinsky, GAC.jpg|300px|center|]]
&lt;div style=&quot;text-align:left; padding: .4em;&quot;&gt;
'''Composizione VII''' (Композиция VII o Zu Komposition 7) è un olio su tela del 1913, realizzato dal pittore russo Vasilij Vasil'evič Kandinskij e conservato nella Galleria Tret'jakov di Mosca.

Prodotto centrale del pittore russo nel periodo 1910-1915, essa è considerata l'opera che certificò la raggiunta maturità creativa da parte di Kandinskij, rappresentando anche l'apice della sua energia creativa. È considerato il più rappresentativo tra i lavori completati durante l'anno del successo internazionale dell'artista, simboleggiando il punto di emancipazione definitivo dell'Astrattismo.

Opera più grande mai realizzata dall'artista per dimensione, facente parte della serie denominata Composizioni, rappresenta un'allegoria dell'Apocalisse, di cui riprende il tema e lo propone in una versione astratta, trasfigurata dalla realtà in una forma composta da sole linee e colori. 

&lt;small&gt;(Please update the interwiki links on [[d:|Wikidata]] of your language version of the article after each week's translation is finished so that all languages are linked to each other.)&lt;/small&gt;
----
[[File:TOTW.svg|24px|]]  ''[[m:Translation of the week|About]] · '''[[m:Translation of the week/Translation candidates|Nominate/Review]]''' · [[m:Translation of the week/MassMessage|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]]''
&lt;/div&gt;
&lt;/div&gt;
--[[User:MediaWiki message delivery|MediaWiki message delivery]] ([[User talk:MediaWiki message delivery|discuss]] • [[Special:Contributions/MediaWiki message delivery|contribs]]) 02:24, 10 August 2026 (UTC)
&lt;!-- Message sent by User:Shizhao@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Translation_of_the_week/MassMessage&amp;oldid=30889664 --&gt;

== Tech News: 2026-33 ==

&lt;section begin=&quot;technews-2026-W33&quot;/&gt;&lt;div class=&quot;plainlinks&quot;&gt;
Latest '''[[m:Special:MyLanguage/Tech/News|tech news]]''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. [[m:Special:MyLanguage/Tech/News/2026/33|Translations]] are available.

'''Updates for editors'''
* [[File:Maki-gift-15.svg|12px|link=|class=skin-invert|Wishlist item]] A new ChartWizard is [[c:Special:ChartWizard/Data:Example.Pie.chart|now available on Wikimedia Commons]] for users interested in creating charts from their own data. The wizard makes the [[mw:Special:MyLanguage/Extension:Chart|Chart extension]] more beginner-friendly by allowing editors to create charts, such as bar and pie charts, without needing to use JSON. Users can still switch to the JSON editor if they prefer. Feedback on the new tool is welcome on the [[m:Talk:Community Wishlist/W414|wish talk page]].
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] View all {{formatnum:19}} community-submitted {{PLURAL:19|task|tasks}} that were [[m:Special:MyLanguage/Tech/News/Recently resolved community tasks|resolved last week]]. For example, an issue where the Wikipedia iOS app’s Picture of the Day widget displayed the same image every day instead of updating daily, has now been fixed. [https://phabricator.wikimedia.org/T430692]

'''Updates for technical contributors'''
* [[mw:Special:MyLanguage/Extension:Math|Math formula]] SVG images will soon be generated in the browser instead of on the server. MathML continues to be generated on the server and renders in the browser without JavaScript. Wikibooks will see this change on 12 August, Wikisource on 19 August and Wikipedia from 20-27 August. You can try this by selecting &quot;{{int:Mw-math-mathjax}}&quot; in your preferences. This change is part of [[mw:Special:MyLanguage/RESTBase/deprecation|deprecating RESTBase]] and [[phab:T431372|deprecating Mathoid]]. [https://phabricator.wikimedia.org/T271001]
* Category pages will soon support sorting entries by the time they are added to a category. This will make it easier to find recently or long-standing categorized pages. It will also improve workflows for maintenance categories such as deletion backlogs and other time-based review tasks. You can use &lt;bdi lang=&quot;zxx&quot; dir=&quot;ltr&quot;&gt;&lt;code&gt;&lt;nowiki&gt;cldsort=timestamp&lt;/nowiki&gt;&lt;/code&gt;&lt;/bdi&gt; URL argument in category view to sort the entries. [https://phabricator.wikimedia.org/T433768]
* [[mw:Special:MyLanguage/Extension:Gadgets|Gadgets]] and user scripts on Wikimedia wikis may now use [[phab:T395347|ES2018 features]] and [[phab:T419142|ES2019 features]] in JavaScript code. Previously, the platform only allowed up to ES2017. MediaWiki validates the source code to protect functionality from syntax errors and to ensure scripts are valid in all [[mw:Special:MyLanguage/Compatibility#Browser_support_matrix|supported browsers]]. [https://phabricator.wikimedia.org/T419142]
* [[File:Reload icon with two arrows.svg|12px|link=|class=skin-invert|Recurrent item]] Detailed code updates later this week: [[mw:MediaWiki 1.47/wmf.16|MediaWiki]]

'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/News/Writers|Tech News writers]] and posted by [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News#contribute|Contribute]]&amp;nbsp;• [[m:Special:MyLanguage/Tech/News/2026/33|Translate]]&amp;nbsp;• [[m:Tech|Get help]]&amp;nbsp;• [[m:Talk:Tech/News|Give feedback]]&amp;nbsp;• [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
&lt;/div&gt;&lt;section end=&quot;technews-2026-W33&quot;/&gt;

&lt;bdi lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;[[User:MediaWiki message delivery|MediaWiki message delivery]]&lt;/bdi&gt; 20:46, 10 August 2026 (UTC)
&lt;!-- Message sent by User:STei (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&amp;oldid=30901051 --&gt;</text>
      <sha1>3qq34o89d79y284q7oc13v6067xax06</sha1>
    </revision>
  </page>
  <page>
    <title>Chess Opening Theory/1. e4/1...c5/2. Nf3/2...e6/3. d4/3...cxd4/4. Nxd4/4...Qb6</title>
    <ns>0</ns>
    <id>463519</id>
    <revision>
      <id>4657066</id>
      <parentid>4612795</parentid>
      <timestamp>2026-08-10T16:02:55Z</timestamp>
      <contributor>
        <username>JCrue</username>
        <id>2226064</id>
      </contributor>
      <minor />
      <comment>not a module</comment>
      <origin>4657066</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1080" sha1="f78pu0xki6m5sguhd7r8ps9pm952fqb" xml:space="preserve">{{Chess Opening Theory/Position|=
|Kveinis variation
|eco=[[Chess/ECOB|B40]]
|parent=[[../|Open Sicilian with e6]]
}}

== 4...Qb6 · Kveinis variation ==

The razor-sharp '''Kveinis variation''' has often been considered inferior to other variations of the Sicilian French Variation, yet statistics show it '''scores better than any other at club level!''' It scores respectably well at grandmaster level, too. 

By playing '''4...Qb6''', Black puts pressure on White's d4 knight and b2 pawn. With the dark-squared bishop ready to add more pressure from c5, Black also '''x-rays f2'''. White must be extremely careful not to make any false moves. The opening is especially efficacious in blitz and bullet games where White might not have time to spot the danger. For example: '''1. e4 c5 2. Nf3 e6 3. d4 cxd4 4. Nxd4 Qb6 5. Nc3 Bc5 6. Nce2 e5 7. Nb3 Bxf2+ 8. Kd2 Qe3#'''

Black must also be extremely careful about capturing White's &quot;poisoned pawn&quot; on b2. It's a tactical mastermind between the two sides that can frequently give rise to tense, exciting middlegames. 

{{bookcat}}</text>
      <sha1>f78pu0xki6m5sguhd7r8ps9pm952fqb</sha1>
    </revision>
  </page>
  <page>
    <title>OpenSSH/Cookbook/The Client Configuration File</title>
    <ns>0</ns>
    <id>466867</id>
    <revision>
      <id>4657086</id>
      <parentid>4641433</parentid>
      <timestamp>2026-08-10T18:01:42Z</timestamp>
      <contributor>
        <username>Schweikhardt</username>
        <id>1008853</id>
      </contributor>
      <minor />
      <comment>Typo corrected</comment>
      <origin>4657086</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="14532" sha1="2puf3rqd1jlcqgs7a3qjk4g3x1tb1ex" xml:space="preserve">&lt;noinclude&gt;{{simple chapter navigation|previous=Remote_Processes|next=Tunnels}}&lt;/noinclude&gt;
&amp;nbsp;

==SSH Client Configuration Files==

Use of the client configuration file, [http://man.openbsd.org/ssh_config ssh_config(5)], is perhaps the most underrated and unrecognized feature, despite its great utility and flexibility.   The configuration file can be used to create shortcuts for specific systems or scenarios by applying designated settings.  The client, [http://man.openbsd.org/ssh.1 ssh(1)], prioritizes settings applied at the command-line as run-time options.  Then the settings from user's own configuration file, usually '''~/.ssh/config''', are applied.  Then, finally, global client settings are applied, usually from the system-wide configuration file, '''/etc/ssh/ssh_config''', if it exits.  So as mentioned in the chapter on [[OpenSSH/Client_Configuration_Files | Client Configuration Files]], the prioritization is as follows:

# run time arguments via the shell
# user's own configuration
# system-wide configuration

Even within the user's configuration file and the system's global configuration file, the first match is applied.  Therefore specific configurations must always go towards the beginning of the file and more general settings towards the end.  

&lt;noinclude&gt;__TOC__&lt;/noinclude&gt;

==Basics of SSH Client Configuration==

Each stanza in the configuration file begins with either a '''Host''' or '''Match''' directive.  The directives within the stanza are then applied, if relevant.  More on '''Match''' later.  Below two hosts are each set up with their own shortcuts using a basic '''Host''' directive.  The settings for the two hosts are followed by two more general stanzas applicable to two whole domains.  Lastly is a stanza with applying '''IdentitiesOnly''' to all outgoing connections.

&lt;syntaxhighlight lang=&quot;apache&quot; line=&quot;1&quot;&gt;
Host www
        HostName www.example.org
        User fred
        IdentityFile %d/.ssh/fred.www.key

Host git
        HostName git.example.org
        User paz
        IdentityFile %d/.ssh/paz.git.key

Host *.example.org
        ConnectTimeout 2
        AddKeysToAgent yes

Host *.example.com
        ConnectTimeout 5
        Port 2022

Host *
        IdentitiesOnly yes
&lt;/syntaxhighlight&gt;

The specific configurations are first and get more general until the end where '''IdentitiesOnly''' gets applied to all outgoing sessions.  Hosts in the ''example.org'' domain use the default SSH port of 22, while that is overridden for those in the ''example.com'' domain which uses port 2022 instead.  Keys are automatically added to the agent when used with the ''example.org'' domain but not with the ''example.com'' domain.  

The first host can be reached with &lt;code&gt;ssh www&lt;/code&gt; and the second host with &lt;code&gt;ssh git&lt;/code&gt;.  In general, it is a good idea to set '''IdentitiesOnly''' so that only the one designated key is tried when authenticating.  Otherwise, the keys are tried in whatever order they might be found in the agent which can be unpredictable.  The result without '''IdentitiesOnly''' can be that the connection gets blocked from having too many failed logins attempts before the right key even gets tried.

===Verifying Client Configurations===

The actual settings used by the client for a connection are assigned first by the run time arguments, then from the user configuration files, and then finally from the system configuration files.  Along the way, there can be more than one layer of decisions made using the '''Match''' directives in the configuration files.  These are affected by the various stages of the destination's name resolution, the account and port being connected to, and the local account, address, and network being connected from.  Matters can be complicated further through the use of the '''exec''' declaration which receives a pass or fail from external scripts or programs.  

The final calculation of settings which will be applied are shown using the client's '''-G''' option.  The client then makes no attempt to actually connect but instead just calculates all the options which would have been used for the hypothetical connection.  As with an actual connection, a host name or shortcut must be supplied.  The defaults are filled in for everything else unless overridden through explicit run time settings.  Then '''-G''' does its work.  

&lt;syntaxhighlight lang=&quot;shell&quot;&gt;
$ ssh -G example.org | sort | less -X 
&lt;/syntaxhighlight&gt;

Optionally, other parameters, such as a remote account name, can be specified.  Additionally, those checked in the '''Match''' stanzas would be relevant to the final calculation of the configuration options.  Those options include '''-b''' to set the source address, '''-l''' to set the destination account, '''-p''' to set the destination port, and '''-P''' to set a configuration Tag.  

&lt;syntaxhighlight lang=&quot;shell&quot;&gt;
$ ssh -G -l fred example.org | sort | less -X 
$ ssh -G git@code.example.com | sort | less -X
$ ssh -G -p 2222 -l fred server.example.org | sort | less -X
$ ssh -G -P detonate -l fred server.example.org | sort | less -X
$ ssh -G -b 192.168.16.17 -l admin intra.example.org | sort | less -X
&lt;/syntaxhighlight&gt;

See [http://man.openbsd.org/ssh_config.5 ssh_config(5)] for more details about '''Match''' and '''Tag''' and [http://man.openbsd.org/ssh.1 ssh(1)] for more about the client's run time options.  See also [http://man.openbsd.org/diff.1 diff(1)] for comparing the output.

&lt;syntaxhighlight lang=&quot;shell&quot;&gt;
$ diff --suppress-common-lines \
        &lt;(ssh -G -l fred garage | sort) \
        &lt;(ssh -G -l foo garage| sort)
&lt;/syntaxhighlight&gt;

The above takes advantage of process substitution&lt;ref name=&quot;Process Substitution&quot;&gt;{{cite web |url=https://mywiki.wooledge.org/ProcessSubstitution |title=Process Substitution | publisher=Greg's Wiki | date=2025-04-19 | access-date=2025-06-02}}&lt;/ref&gt; to compare the difference in client settings when connecting to two different remote accounts at the shortcut ''garage''.  Process substitution is available in many shells, but not all.

==Multiple Shortcuts==

Each stanza can have multiple shortcuts.  

&lt;syntaxhighlight lang=&quot;apache&quot; line=&quot;1&quot;&gt;
Host w www www.example.org
        HostName www.example.org
        User fred
        IdentityFile %d/.ssh/example.org-fred.ed25519
&lt;/syntaxhighlight&gt;

Above, the same host can be reached with &lt;code&gt;ssh w&lt;/code&gt;, &lt;code&gt;ssh www&lt;/code&gt;, or &lt;code&gt;ssh www.example.org&lt;/code&gt;.  

==Different Keys for Different Accounts on the Same Remote Host==

Sometimes it is necessary to access multiple accounts on the same remote system, each with a separate key.  The '''Match''' block in [http://man.openbsd.org/ssh_config ssh_config(5)] can pair each account with its corresponding key.  

&lt;syntaxhighlight lang=&quot;apache&quot; line=&quot;1&quot;&gt;
Match host www.example.org user git
        IdentityFile %d/.ssh/example.org-git.ed25519

Match host www.example.org user fred
        IdentityFile %d/.ssh/example.org-fred.ed25519

Match host www.example.org user backup
        IdentityFile %d/.ssh/example.org-backup.ed25519

Host www.example.org
        IdentitiesOnly yes
        AddKeysToAgent yes
&lt;/syntaxhighlight&gt;

Above, different keys are applied to the same remote host depending on which of the three accounts is used.

==Automatically Fire Up Local VNC After Establishing A Tunnel==

The '''LocalCommand''' directive can launch a local program upon successful authentication.  If that is combined with other directives, there are a lot of possibilities.  Here once a VNC tunnel gets established, the client is connected to it.  

&lt;syntaxhighlight lang=&quot;apache&quot; line=&quot;1&quot;&gt;
Host make-tunnel tunnel
        Hostname 198.51.100.120
        User tunneler
        IdentitiesOnly yes
        IdentityFile %d/.ssh/tunneler-vnc-tunnel
        LocalForward 5900 localhost:5900
        ExitOnForwardFailure yes
        PermitLocalCommand yes
        LocalCommand remmina -c vnc://localhost:0
&lt;/syntaxhighlight&gt;

The '''LocalForward''' creates the tunnel, while the '''PermitLocalCommand''' and '''LocalCommand''' connects the client to the tunnel once the tunnel is complete.  Should the tunnel fail, '''ExitOnForwardFailure''' ensures that the SSH session ends so that the failure can be properly investigated rather than the client connected to nothing.  

===VNC Through A Jointly Accessible External Host - Approach One===

Networking through one or more layers of NAT can be a problem. That is especially the case as Carrier Grade NAT becomes more common in the legacy IPv4 networks provided by an increasing number of service providers.  It is possible to connect two endpoints via a publicly accessible third machine on common ground.  If there are three systems, A, B, and C, where A needs to connect to C, neither A nor C can connect directly to the other yet both can reach host B, then it is possible to make a tunnel via B if both A and C can reach it.  Both A and C need to have working accounts on C, even if just for forwarding.  Full shell access is not required.  

On host B, accounts are needed for C and A.  

On host C:
&lt;syntaxhighlight lang=&quot;apache&quot; line=&quot;1&quot;&gt;
Host hostc
        HostName server.example.com
        IdentityFile %d/.ssh/hostc.ed25519
        AddKeysToAgent yes
        RemoteForward 7900 localhost:5900
        RemoteForward 7901 localhost:5901
&lt;/syntaxhighlight&gt;

Start the VNC server and then have the system establish an SSH connection to host B with &lt;code&gt;ssh hostc&lt;/code&gt;.  The configuration of host B really needs no modification, unless if the key for the tunnel should be locked down or other restrictions desired.  

On host A:
&lt;syntaxhighlight lang=&quot;apache&quot; line=&quot;1&quot;&gt;
Host tunnel
        LocalForward 5900 localhost:7900
        LocalForward 5901 localhost:7901
        PermitLocalCommand yes
        LocalCommand remmina -c vnc://localhost:0
        ExitOnForwardFailure yes
&lt;/syntaxhighlight&gt;

Start the SSH connection by entering &lt;code&gt;ssh tunnel&lt;/code&gt; and Remmina will connect automatically to host C via the tunnel on Host C.

==System-wide Client Defaults==

The system-wide client configuration file, '''/etc/ssh/ssh_config''', is a convenient way to provide what are effectively new, local default settings.  As mentioned many times, configuration options are applied with a first match priority therefore any system-wide, global options should be as general as possible.  System-wide defaults shine when customizing the local environment, including LAN access be means such as Kerberos authentication or even [[OpenSSH/Cookbook/Host-based_Authentication‎|Host-based&amp;nbsp;Authentication]], the latter is covered in its own chapter.  

&lt;syntaxhighlight lang=&quot;apache&quot; line=&quot;1&quot;&gt;
Host 172.16.4.*
        HostKeyAlias a.pool.example.org
        ConnectTimeout 4

Host 172.16.5.*
        HostKeyAlias b.pool.example.org
        ConnectTimeout 2

Host 172.16.*
        HostbasedAuthentication yes

Host *
        IdentitiesOnly yes
&lt;/syntaxhighlight&gt;

The above allows host-based authentication for a specific subnet.  It also sets '''IdentitiesOnly''' globally.  

&lt;syntaxhighlight lang=&quot;apache&quot; line=&quot;1&quot;&gt;
Host *.pool.example.org
        VerifyHostKeyDNS no
        GSSAPIAuthentication yes
        GSSAPIKeyExchange yes
        GSSPITrustDNS yes
        GSSAPIRenewalForcesRekey yes
        GSSAPIDelegateCredentials yes
&lt;/syntaxhighlight&gt;

The above sets system-wide options for all systems in the '''pool.example.org''' domain, such that Kerberos authentication is possible.  

The manual page for [http://man.openbsd.org/ssh_config ssh_config(5)] has a section on &quot;tokens&quot; which can be used in the stanzas in place of system information, such as the remote host name, the remote account name, or the local account name, to name just a few.  These are useful when setting the system-wide client configuration file in '''/etc/ssh/ssh_config''' or '''/etc/ssh/ssh_config.d/*''' for all local accounts.  

===Tokens===

Some client configuration directives can make use of tokens to stand in for certain values, as determined at run time.  

'''LocalCommand''' accepts all tokens.

'''Hostname''' accepts the tokens %% and %h.

'''ProxyCommand''' and '''ProxyJump''' accept the tokens %%, %h, %n, %p, and %r.

'''CertificateFile''', '''ControlPath''', '''IdentityAgent''', '''IdentityFile''', '''KnownHostsCommand''', '''LocalForward''', '''Match exec''', '''RemoteCommand''', '''RemoteForward''', '''RevokedHostKeys''', and '''UserKnownHostsFile''' accept the tokens %%, %C, %d, %h, %i, %j, %k, %L, %l, %n, %p, %r, and %u.

'''KnownHostsCommand''' additionally accepts the tokens %%, %C, %d, %f, %H, %h, %I, %i, %j, %K, %k, %L, %l, %n, %p, %r, %t, and %u.

The client tokens are described as follows, and are somewhat different from the tokens used in server configuration:

{| class=&quot;wikitable&quot; style=&quot;caption-side: bottom;&quot;
|+ Lookup Table of OpenSSH Client Configuration Tokens
|- style=&quot;border-bottom: thick solid #000;&quot;
! Token
! Description
|-
! %%
| A literal ‘%’.
|-
! %C
| The hash of %l%h%p%r%j.
|-
! %d
| The local account's home directory.
|-
! %f
| The fingerprint of the remote server's host key.
|-
! %H
| The '''known_hosts''' host name or address searched for.
|-
! %h
| The remote host name.
|-
! %I
| The reason for a '''KnownHostsCommand''' execution: either ADDRESS when looking up the host by address (only when '''CheckHostIP''' is enabled), HOSTNAME when searching by host name, or ORDER when preparing the host key algorithm preference list to use for the destination host.
|-
! %i
| The local account's UID.
|-
! %j
| The contents of the '''ProxyJump option''', or an empty string if this option is unset.
|-
! %K
| The base64-encoded remote server's host key.
|-
! %k
| The host key alias if specified, otherwise the original remote host name as given on the command line.
|-
! %L
| The local host name.
|-
! %l
| The local host name, including the domain name.
|-
! %n
| The original remote host name, as given on the command line.
|-
! %p
| The remote port.
|-
! %r
| The remote account name.
|-
! %T
| The local [http://man.openbsd.org/tun  tun(4)] or [http://man.openbsd.org/tap tap(4)] network interface assigned if tunnel forwarding was requested, otherwise &quot;NONE&quot;.
|-
! %t
| The type of the server host key, e.g. ssh-ed25519.
|-
! %u
| The local account name.
|}

As always, check [http://man.openbsd.org/ssh_config ssh_config(5)] on the systems in question to know what is actually supported by the installed version of OpenSSH.  

{{BookCat}}
{{status|100%}}
&lt;noinclude&gt;{{OpenSSH/TOC|mini}}
&lt;/noinclude&gt;</text>
      <sha1>2puf3rqd1jlcqgs7a3qjk4g3x1tb1ex</sha1>
    </revision>
  </page>
  <page>
    <title>User:JustTheFacts33/sandbox</title>
    <ns>2</ns>
    <id>468255</id>
    <revision>
      <id>4657063</id>
      <parentid>4656690</parentid>
      <timestamp>2026-08-10T15:52:08Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <comment>/* Former partner factories */</comment>
      <origin>4657063</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="441981" sha1="em697igziv1onwlvjqee0y5vovsltze" xml:space="preserve">This is a '''history of [[w:General Motors|General Motors]] factories''' that are being or have been used to produce cars, vans, SUVs, trucks, buses, and automobile components.&lt;ref name=GMfacilities&gt;[https://web.archive.org/web/20080614231130/http://www.gm.com/corporate/responsibility/environment/plants/index.jsp GM facilities map]. Retrieved on July 8, 2009.&lt;/ref&gt; The factories are sometimes idled for re-tooling. 

Originally, GM's different divisions each had their own serial number formats and plant codes. Chevrolet cars, Pontiac, Oldsmobile, and Buick unified their serial number formats and plant codes in 1965. Cadillac adopted the same unified format in 1971. Chevrolet trucks and GMC trucks unified their serial number formats in 1972. Chevrolet trucks and GMC trucks were already using the same plant codes from 1964 and those were unified with the car divisions (other than Cadillac) in 1965. Cadillac did not use plant codes before 1971 as all Cadillacs were made at Cadillac's home plant in Detroit until 1971. In 1971, Cadillacs began to be made in more than one plant so they started using plant codes, using the same codes that the other GM car divisions were using since 1965. GM Canada used the same format as GM USA from 1967.

For US-built models:

For '''Chevrolet cars including El Camino''': Plant code was the 1st or 1st 2 digits of the serial number from 1928-1952. Plant code was the 4th position of the serial number from 1953-1957 6-cylinder models. Plant code was the 5th position of the serial number from 1955-1957 V8 models. Plant code was the 4th position of the serial number from 1958-1959. Plant code was the 6th position of the serial number from 1960-1964. Plant code was the letter or number in the 7th position of the serial number from 1965-1980.

For '''Chevrolet trucks''': Plant code was the 1st or 1st 2 digits of the serial number from 1947-1952. Plant code was the 4th position of the serial number from 1953-1954 &amp; for the 1955 1st Series models. Plant code was the 5th position of the serial number for 1955 2nd Series models and 1956-1959 models with 6-cylinder engines. Plant code was the 6th position of the serial number for 1955 2nd Series models and 1956-1959 models with V8 engines. Plant code was the 6th position of the serial number from 1960-1971. Plant code was the letter or number in the 7th position of the serial number from 1972-1980.

For '''Pontiac''': Plant code was the 1st letter in the serial number from 1936-1938 for plants other than Pontiac, MI (Pontiac, MI omitted the 1st letter so the 1st position was a number rather than a letter for Pontiac, MI as Pontiac, MI didn't use a specific plant code). Plant code was the 1st position of the serial number from 1939-1958. Plant code was the 4th position of the serial number from 1959-1964. Plant code was the letter or number in the 7th position of the serial number from 1965-1980.

For '''Oldsmobile''': Plant code was the 1st of 2 letters in the serial number from 1937-1940 for plants other than Lansing (Lansing omitted the 1st letter so there was only 1 letter before the numbers rather than 2 letters for Linden &amp; Southgate as Lansing didn't have a specific plant code). Plant code was the letter in the 3rd position of the serial number from 1941-1948 for plants other than Lansing (Lansing omitted the letter and didn't have a specific plant code). Plant code was the 4th position of the serial number from 1949-1964. Plant code was the letter or number in the 7th position of the serial number from 1965-1980.

For '''Buick''': Plant code was the number in the 1st position of the serial number from 1938-1953. Plant code was the number in the 3rd position of the serial number from 1954-1964. Plant code was the letter or number in the 7th position of the serial number from 1965-1980.

For '''Cadillac''': Plant code was the letter or number in the 7th position of the serial number from 1971-1980. (Cadillac did not use plant codes before 1971 as all Cadillacs were made at Cadillac's home plant in Detroit until 1971.)

For '''GMC Sprint &amp; Caballero''': Plant code was the letter or number in the 7th position of the serial number from 1971-1980.

For '''GMC trucks''': Plant code was the 6th position of the serial number from 1952-1954 &amp; for 1955 1st Series models with manual transmission. Plant code was the 7th position of the serial number from 1952-1954 &amp; for 1955 1st Series models with automatic transmission. Plant code was the 4th position of the serial number for 1955 2nd Series models and 1956-1959 models with 6-cylinder engines. Plant code was the 5th position of the serial number for 1955 2nd Series models and 1956-1959 models with V8 engines. Plant code was the 5th position of the serial number for 1960-1966 models with 2wd and V6 or V8 engines. Plant code was the 6th position of the serial number for 1960-1966 models with inline-6 engines or with 4wd. Plant code was the 7th position of the serial number from 1967-1971 (most models had a dash in the 6th position except for some models that had a special designation indicated in the 6th position). Plant code was the letter or number in the 7th position of the serial number from 1972-1980.

All models from 1981 on have the plant code in the 11th position as per standardized VIN regulations. 

The above applies to Canadian-built models from 1967 on.

==Current factories== 

 
{| class=&quot;wikitable sortable&quot; style=&quot;font-size:90%&quot; 

!VIN !! Name !! City/State !! Country !! class=&quot;unsortable&quot; | Products !! Opened !! Idled !! class=&quot;unsortable&quot; | Comments 

|- 

|R (1963-1964 [[w:Chevrolet|Chevrolet]] and 1965-present)&lt;br /&gt;&lt;br /&gt;T (Pre-1965 [[w:Oldsmobile|Oldsmobile]] and Pre-1960 [[w:Pontiac (automobile)|Pontiac]])&lt;br /&gt;&lt;br /&gt;A (1960-1964 [[w:Pontiac (automobile)|Pontiac]])&lt;br /&gt;&lt;br /&gt;8 (Pre-1964 [[w:Buick|Buick]])||[[w:Arlington Assembly|Arlington Assembly]]||[[w:Arlington, Texas|Arlington, Texas]]||[[w:United States|United States]]||[[w:GMT T1XX|T1XX]] SUVs (2021-):&lt;br /&gt;
[[w:Chevrolet Tahoe#Fifth generation (2021)|Chevrolet Tahoe]]&lt;br /&gt;[[w:Chevrolet Suburban#Twelfth generation (2021)|Chevrolet Suburban]]&lt;br /&gt;[[w:Chevrolet Tahoe#Yukon|GMC Yukon]]&lt;br /&gt;[[w:Chevrolet Suburban#Yukon XL|GMC Yukon XL]]&lt;br /&gt;[[w:Cadillac Escalade#Fifth generation (2021)|Cadillac Escalade]]&lt;br /&gt;[[w:Cadillac Escalade#Fifth generation (2021)|Cadillac Escalade ESV]]
||1954||&amp;nbsp;||Located at 2525 E Abram St.&lt;br /&gt;Was originally part of the [[w:Buick-Oldsmobile-Pontiac Assembly Division|Buick-Oldsmobile-Pontiac Assembly Division]]. Production began on January 6, 1954. The first vehicle produced was a 1954 Pontiac Chieftain 4-door. Arlington began making Chevrolet passenger cars for 1963. BOP Assembly Division became GM Assembly Division in 1965. Arlington began making midsize cars for 1968 but focused exclusively on midsize cars from 1971-1987. Arlington resumed making full-size cars for 1988 for the first time since 1970. Arlington focused exclusively on rwd, full-size cars from 1988-1996. When Willow Run Assembly closed in 1993, Arlington became GM's only factory still building traditional body-on-frame, rwd, full-size cars. Passenger car production ended in 1996. It's interesting to note that Arlington has never built any fwd vehicles or any unibody vehicles. Arlington was then converted to build full-size SUVs. SUV production began for 1998. Full-size pickups were also built for 1998-2000. Arlington Assembly has produced models for all of GM's primary American brands: Chevrolet, Pontiac, Oldsmobile, Buick, Cadillac, and GMC. Arlington Assembly has produced over 13 million vehicles. A new 129,250-square-foot body shop on the plant's west side was announced in 2011 as part of retooling for the K2XX generation SUVs launched in 2014. A new stamping plant was announced in 2012 and opened in 2013 at Arlington Assembly, replacing stampings previously sourced from GM stamping plants elsewhere in the US.&lt;br /&gt; A $1.4 billion plant upgrade was completed to build the &lt;br /&gt; T1XX generation SUVs beginning in 2020. It included a new &lt;br /&gt; 1 million sq. ft. body shop &amp; a 600,000-sq. ft. extension to the paint shop. The general assembly area was also upgraded. &lt;br /&gt; Past models:&lt;br /&gt; [[w:GM A platform (RWD)|GM A platform (RWD)]] (intermediate): [[w:Chevrolet Chevelle|Chevrolet Chevelle]] (1970-1977), [[w:Chevrolet El Camino|Chevrolet El Camino]] (1974-1981), [[w:Chevrolet Malibu|Chevrolet Malibu]] (1978-1981), [[w:Chevrolet Monte Carlo|Chevrolet Monte Carlo]] (1970-1981), [[w:GMC Sprint|GMC Sprint]] (1974-1977), [[w:GMC Caballero|GMC Caballero]] (1978-1981), [[w:Oldsmobile Cutlass|Oldsmobile Cutlass]] (1971-1981), [[w:Oldsmobile Cutlass Supreme|Oldsmobile Cutlass Supreme]] (1971-1981), [[w:Oldsmobile 442|Oldsmobile 442]] (1971-1977), [[w:Pontiac GTO|Pontiac GTO]] (1968-1970), [[w:Pontiac LeMans|Pontiac LeMans]] (1968-1970), [[w:Pontiac Tempest|Pontiac Tempest]] (1968-1970)&lt;br /&gt; [[w:General Motors G platform (1969)|GM G platform (RWD) 1982-1988]]: [[w:Buick Regal|Buick Regal]] (1982-1983), [[w:Chevrolet El Camino|Chevrolet El Camino]] (1982-1984), [[w:Chevrolet Malibu|Chevrolet Malibu]] (1982-1983), [[w:Chevrolet Monte Carlo|Chevrolet Monte Carlo]] (1982-1987), [[w:GMC Caballero|GMC Caballero]] (1982-1984), [[w:Oldsmobile Cutlass Supreme|Oldsmobile Cutlass Supreme]] (1982-1987), [[w:Oldsmobile 442|Oldsmobile 442]] (1985).&lt;br /&gt; [[w:General Motors A platform (1925)|GM full-size A platform]]: [[w:Pontiac Chieftain|Pontiac Chieftain]] (1954-1957), [[w:Pontiac Star Chief|Pontiac Star Chief]] (1954-1957)&lt;br /&gt; [[w:GM B platform|GM B platform]]: [[w:Buick Century#Second generation (1954–1958)|Buick Century]] (1954-1958), [[w:Buick Invicta|Buick Invicta]] (1959-1963), [[w:Buick LeSabre|Buick LeSabre]] (1959-1960), [[w:Buick Roadmaster#1991–1996|Buick Roadmaster sedan]] (1992-1996), [[w:Buick Estate#1991–1996|Buick Roadmaster Estate wagon]] (1994-1996), [[w:Buick Special#1949–1958|Buick Special]] (1954-1958), [[w:Buick Wildcat|Buick Wildcat]] (1963), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1963-1970), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1963-1970), [[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-1970, 1988-1996), [[w:Chevrolet Impala|Chevrolet Impala]] (1963-1970), [[w:Chevrolet Impala#Seventh generation (Impala SS, 1994–1996)|Chevrolet Impala SS]] (1994-1996), [[w:Oldsmobile 88|Oldsmobile 88]] (1955-1964), [[w:Oldsmobile Custom Cruiser#Second generation (1977–1990)|Oldsmobile Custom Cruiser]] (1988-1990), [[w:Oldsmobile Starfire#First generation (1961–1966)|Oldsmobile Starfire]] (1961-1966), [[w:Pontiac 2+2|Pontiac 2+2]] (1964-1967), [[w:Pontiac Bonneville|Pontiac Bonneville]] (1959-1968), [[w:Pontiac Catalina|Pontiac Catalina]] (1959-1970), [[w:Pontiac Grand Prix|Pontiac Grand Prix]] (1962-65, 1967-68), [[w:Pontiac Star Chief|Pontiac Star Chief]] (1963, 1966), [[w:Pontiac Ventura#1960–1970|Pontiac Ventura]] (1960-1961).&lt;br /&gt;[[w:General Motors C platform (RWD)|GM C platform (RWD)]]: [[w:Buick Electra|Buick Electra]] (1959-1963), [[w:Buick Limited#1958 Limited|Buick Limited]] (1958), [[w:Buick Roadmaster|Buick Roadmaster]] (1955-1958), [[w:Buick Super|Buick Super]] (1955-1958), [[w:Oldsmobile 98|Oldsmobile 98]] (1954-1964) &lt;br /&gt; [[w:GM D platform|GM D platform]]: [[w:Cadillac Brougham|Cadillac Brougham]] (1988-1992), [[w:Cadillac Fleetwood#Rear-wheel drive 1993–1996|Cadillac Fleetwood]] (1993-1996) &lt;br /&gt;[[w:GMT400|GMT400]] pickups: [[w:Chevrolet C/K (fourth generation)|Chevrolet C/K]] (1998-2000), [[w:Chevrolet C/K (fourth generation)|GMC Sierra]] (1998-2000).&lt;br /&gt; [[w:GMT400|GMT400]] SUVs: [[w:Chevrolet Tahoe#First generation (1992)|Chevrolet Tahoe]] (1998-1999), [[w:Chevrolet Tahoe#Tahoe Limited and Tahoe Z71|Chevrolet Tahoe Limited and Z71]] (2000), [[w:Chevrolet Tahoe#First generation (1992)|GMC Yukon]] (1998-1999), [[w:Chevrolet Tahoe#GMC Yukon Denali|GMC Yukon Denali]] (1999-2000), [[w:Cadillac Escalade#First generation (1999)|Cadillac Escalade]] (1999-2000)&lt;br /&gt; [[w:GMT800|GMT800]] SUVs: [[w:Chevrolet Tahoe#Second generation (2000)|Chevrolet Tahoe]] (2001-2006), [[w:Chevrolet Tahoe#Second generation (2000)|GMC Yukon]] (2001-2006), [[w:Cadillac Escalade#Second generation (2002)|Cadillac Escalade]] (2002-2006), [[w:Chevrolet Suburban#Ninth generation (2000)|Chevrolet Suburban]] (2001-2005), [[w:Chevrolet Suburban#Ninth generation (2000)|GMC Yukon XL]] (2001-2005).&lt;br /&gt; [[w:GMT900|GMT900]] SUVs: [[w:Chevrolet Tahoe#Third generation (2007)|Chevrolet Tahoe]] (2007-2014), [[w:Chevrolet Tahoe#Third generation (2007)|GMC Yukon]] (2007-2014), [[w:Chevrolet Tahoe#Third generation (2007)|GMC Yukon Denali]] (2009-2014), [[w:Cadillac Escalade#Third generation (2007)|Cadillac Escalade]] (2007-2014), [[w:Chevrolet Suburban#Tenth generation (2007)|Chevrolet Suburban]] (2007-2014), [[w:Chevrolet Suburban#Tenth generation (2007)|GMC Yukon XL]] (2007-2014), [[w:Chevrolet Suburban#Tenth generation (2007)|GMC Yukon XL Denali]] (2009-2014), [[w:Cadillac Escalade#Third generation (2007)|Cadillac Escalade ESV]] (2007-2014)&lt;br /&gt; [[w:GMT K2XX|K2XX]] SUVs (2015-2020): [[w:Chevrolet Tahoe#Fourth generation (2015)|Chevrolet Tahoe]], [[w:Chevrolet Tahoe#Fourth generation (2015)|GMC Yukon]], [[w:Cadillac Escalade#Fourth generation (2015)|Cadillac Escalade]], [[w:Chevrolet Suburban#Eleventh generation (2015)|Chevrolet Suburban]], [[w:Chevrolet Suburban#Eleventh generation (2015)|GMC Yukon XL]], [[w:Cadillac Escalade#Fourth generation (2015)|Cadillac Escalade ESV]] 

|-

|U||[[Artisan Center]]||[[w:Warren, Michigan|Warren, Michigan]]||United States||[[w:Cadillac Celestiq|Cadillac Celestiq]] (2025-)||2024||&amp;nbsp;||Located at the [[w:General Motors Technical Center|GM Global Technical Center]] in Warren, Michigan. The Celestiq will be the first production vehicle sold to the public to be built at the GM Tech Center. The Celestiq will be built by hand on a special, low-volume production line and will be highly customizable. The Celestiq will be built to order and each one will be unique.

|-

|&amp;nbsp;||[[Bay City Powertrain]]||[[w:Bay City, Michigan|Bay City, Michigan]]||United States||Engine components including connecting rods &amp; camshafts||1916||&amp;nbsp;||Located at 1001 Woodside Ave. Originally opened as National Cycle Manufacturing Co. in 1892 to make bicycles. Bought by Chevrolet in 1916 and joined GM along with Chevrolet in 1918. 

|- 

|&amp;nbsp;||[[Bedford Casting]]||[[w:Bedford, Indiana|Bedford, Indiana]]||United States||Cylinder heads, cylinder blocks, transmission cases, EV drive unit housings, structural components, Aluminum die casting||1942||&amp;nbsp;||Located at 105 GM Drive. 

|- 

|5||[[w:Bowling Green Assembly Plant|Bowling Green Assembly Plant]]||[[w:Bowling Green, Kentucky|Bowling Green, Kentucky]]||United States||[[w:Chevrolet Corvette (C8)|Chevrolet Corvette (C8)]] (2020-)&lt;br /&gt; 


[[w:General Motors LS-based small-block engine#LT4|LT4 supercharged V8 engine]] for:&lt;br /&gt; Cadillac CT5-V Blackwing '22- and &lt;br /&gt; Cadillac Escalade-V '23-&lt;br /&gt; 


[[w:Chevrolet Gemini small-block engine|LT6 V8 engine]] ('23- Corvette Z06)

[[w:Chevrolet Gemini small-block engine#LT7|LT7 twin-turbo V8 engine]] ('25- Corvette ZR1, '26- Corvette ZR1X)

||1981||&amp;nbsp;||Located at 600 Corvette Drive. Originally built by Chrysler's Airtemp division in 1969-1970 and used to build non-automotive A/C units, the plant closed in 1976 following Chrysler's sale of Airtemp to Fedders and was sold to GM in 1980. GM converted the facility into an automotive assembly plant and began building Corvettes in Bowling Green during June 1981, taking over production from the St. Louis plant.&lt;br/&gt; 

Past models: &lt;br /&gt; 

[[w:Chevrolet Corvette (C3)|Chevrolet Corvette (C3)]] (1981-1982)&lt;br /&gt;[[w:Chevrolet Corvette (C4)|Chevrolet Corvette (C4)]] (1984-1996)&lt;br /&gt;[[w:Chevrolet Corvette (C5)|Chevrolet Corvette (C5)]] (1997-2004)&lt;br /&gt;[[w:Chevrolet Corvette (C6)|Chevrolet Corvette (C6)]] (2005-2013)&lt;br /&gt;[[w:Chevrolet Corvette (C7)|Chevrolet Corvette (C7)]] (2014-2019)  

[[w:Cadillac XLR|Cadillac XLR]] (2004-2009)&lt;br /&gt;

Performance Build Center relocated from Wixom, MI to Bowling Green Assembly in 2014.&lt;br/&gt; Past engines: [[w:Cadillac twin-turbo V8|Cadillac Blackwing 4.2L LTA twin-turbo V8]],&lt;br /&gt;[[w:General Motors LS-based small-block engine#LT4|LT4 supercharged V8 engine]] for: Chevrolet Corvette Z06 (C7) (2015-2016 models with Z07 package or build your own engine option, 2017-2019 all Z06 models) &amp;&lt;br /&gt; Chevrolet Camaro ZL1 (Gen 6) (phased in during 2020, all '21-'24),&lt;br /&gt;[[w:General Motors LS-based small-block engine#LT5|LT5 supercharged 6.2L Gen V Small Block V8]] ('19 Corvette ZR1)

|-

|&amp;nbsp;||[[Brownstown Battery Assembly Plant]]||[[w:Brownstown Charter Township, Michigan|Brownstown Charter Township, Michigan]]||United States||Battery packs for [[w:Chevrolet Corvette (C8)|Chevrolet Corvette &lt;br&gt; E-Ray]] &amp; [[w:Cadillac Celestiq|Cadillac Celestiq]]&lt;br /&gt;Electric drive units for Chevrolet Corvette &lt;br&gt; E-Ray&lt;br /&gt;Assembles prototype battery packs||2009||&amp;nbsp;||Located at 20001 Brownstown Center Dr.&lt;br /&gt; Battery packs for [[w:Chevrolet Volt|Chevrolet Volt]], [[w:Holden Volt|Holden Volt]], [[w:Opel Ampera|Opel/Vauxhall Ampera]], [[w:Cadillac ELR|Cadillac ELR]], [[w:Chevrolet Spark#Spark EV|Chevrolet Spark EV (2015-2016 only - LG Chem cells)]], [[w:GMC Hummer EV|GMC Hummer EV]], &amp; [[w:Cadillac Lyriq|Cadillac Lyriq]] &lt;br /&gt; Roof module for [[w:Cruise AV|Cruise AV]]

 
|- 

|6&lt;br /&gt;9&amp;nbsp;(BrightDrop)||[[w:CAMI Automotive|CAMI Automotive]]||[[w:Ingersoll, Ontario|Ingersoll, Ontario]]||[[w:Canada|Canada]]||Assembles Ultium battery cells into modules and packs for BrightDrop Zevo &amp; other vehicles made elsewhere||1989||&amp;nbsp;||Located at 300 Ingersoll St. S. Originally, a 50/50 joint venture with [[w:Suzuki|Suzuki]] until December 2009 when GM bought Suzuki's share. Chevy Equinox production ended April 29, 2022. After being retooled, CAMI reopened December 5, 2022 building the BrightDrop Zevo 600. In July 2023, GM announced a 400,000 square-foot expansion to assemble battery modules and packs. Plant idled in October 2023 and restarted in April 2024. Production was suspended in May 2025. On October 21, 2025, GM announced that the BrightDrop van was discontinued and would not resume production anywhere.
Past models: [[w:BrightDrop Zevo 600|BrightDrop Zevo 600]] (2023-2024)&lt;ref&gt;{{Cite news |author=Tom Venetis |date=4 April 2022 |title=GM Canada Electric Vehicle Production in Ontario by the End of 2022 |work=Metroland Media Group |url=http://www.canadianautoworld.ca/industry-news/gm-canada-electric-vehicle-production-in-ontario-by-the-end-of-2022 |access-date=24 April 2022}}&lt;/ref&gt;,&lt;br&gt; [[w:BrightDrop Zevo 400|BrightDrop Zevo 400]] (2024),&lt;br&gt;[[w:Chevrolet BrightDrop|Chevrolet BrightDrop 400]] (2025),&lt;br /&gt;[[w:Chevrolet BrightDrop|Chevrolet BrightDrop 600]] (2025),&lt;br /&gt; [[w:Chevrolet Equinox|Chevrolet Equinox]] (2005-2022)&lt;ref&gt;{{Cite news |author=Bryan Bicknell |date=3 March 2022 |title=The finish line draws closer for gas powered vehicles at Ontario CAMI plant |work=CTV News |url=https://london.ctvnews.ca/the-finish-line-draws-closer-for-gas-powered-vehicles-at-ontario-cami-plant-1.5804523 |access-date=17 May 2022}}&lt;/ref&gt;, [[w:Pontiac Torrent|Pontiac Torrent]] (2006-09), [[w:GMC Terrain#First generation (2010)|GMC Terrain]] (2010-2017), [[w:Suzuki XL-7#Second generation (XL7; 2006)|Suzuki XL7]] (2007-2009), [[w:Geo Tracker|Geo/Chevrolet Tracker]] (1990-2004),&lt;br&gt; [[w:Chevrolet Tracker (Americas)#Canada|Asuna/Pontiac Sunrunner]] (Canada only) (1992-1998),&lt;br&gt; [[w:Suzuki Vitara#First generation (ET/TA; 1988)|Suzuki Sidekick]] (1990-1998), [[w:Suzuki Grand Vitara|Suzuki Vitara]] (1999-2004), [[w:Geo Metro|Geo/Chevrolet Metro]] (1990-2001), [[w:Geo Metro|Suzuki Swift]] (1991-2001), [[w:Geo Metro|Pontiac Firefly]] (Canada only) (1991, 1994-2001). 

|- 

|B (Suburban HD)||[[w:GM Defense|GM Defense]] Manufacturing Customer Innovation Center (MCIC)||[[w:Concord, North Carolina|Concord, North Carolina]]||United States|| [[w:M1301 Infantry Squad Vehicle|M1301 Infantry Squad Vehicle]] (ISV),&lt;br /&gt;[[w:Chevrolet Suburban#HD SUV|Chevrolet Suburban Shield]] (a.k.a. HD SUV) (2024-) ||2021||&amp;nbsp;||Located at 4280 Defender Way. Located next to Hendrick Motorsports, a partner in the ISV program. The ISV program for the US Army is based on the Chevrolet Colorado ZR2. The HD SUV program for the US State Dept. Diplomatic Security Service is based on the T1XX-generation Chevrolet Suburban but with a different chassis and frame to support higher vehicle weight, payload, and GVWR than civilian Suburbans. 

|-

|&amp;nbsp;||[[Defiance Foundry]]||[[w:Defiance, Ohio|Defiance, Ohio]]||United States||Aluminum engine blocks &amp; heads||1948||&amp;nbsp;||Located at 26427 State Route 281. Was part of GM's Central Foundry Division. Iron pouring ended in 2017.  The plant now pours only aluminum blocks and heads. Defiance made the aluminum blocks and heads for the Buick 215 V8. Defiance has also supplied [[w:Toyota|Toyota]] with 4-cylinder engine blocks and [[w:Nissan|Nissan]] with V6 engine blocks.  

|- 

|U||[[w:Detroit/Hamtramck Assembly|Detroit/Hamtramck Assembly]]&lt;br /&gt; &quot;Factory ZERO&quot;||[[w:Hamtramck, Michigan|Hamtramck, Michigan]] &amp; [[w:Detroit, Michigan|Detroit, Michigan]]||United States||[[w:GMC Hummer EV|GMC Hummer EV]] pickup (2022-)&lt;br /&gt;[[w:GMC Hummer EV|GMC Hummer EV]] SUV (2024-)&lt;br /&gt;[[w:Chevrolet Silverado EV|Chevrolet Silverado EV]] (2024-)&lt;br /&gt;[[w:GMC Sierra EV|GMC Sierra EV]] (2024-)&lt;br /&gt;[[w:Cadillac Escalade IQ|Cadillac Escalade IQ]] (2025-)&lt;br /&gt;[[w:Cadillac Escalade IQ|Cadillac Escalade IQL]] (2026-)&lt;br /&gt;Assembles Ultium battery cells into modules and packs for a variety of vehicles||1985||&amp;nbsp;||Located at 2500 East Grand Blvd. Sometimes called the &quot;Poletown&quot; plant after the Detroit neighborhood where the plant is located. Part of the site was previously the &quot;Dodge Main&quot; plant which opened in 1911 before Dodge was part of the Chrysler Corp. and closed on January 4, 1980. GM bought the closed plant in 1981. Additional land including residential neighborhoods was acquired through the use of eminent domain. The plant straddles the line between 2 cities: Detroit &amp; Hamtramck. The body shop is in Hamtramck while the general assembly area is in Detroit.&lt;ref&gt;{{Cite web|url=https://www.freep.com/story/money/cars/general-motors/2020/10/16/gm-detroit-hamtramck-assembly-plant-renamed-factory-zero/3665925001/|title = GM's Detroit-Hamtramck Assembly plant renamed 'Factory ZERO' amid shift to all-electric|author=Jamie LaReau|publisher=Detroit Free Press|date=October 16, 2020}}&lt;/ref&gt; The current site includes a 16.5-acre wildlife habitat. Originally built E/K models. First vehicle produced was a 1986 Cadillac Eldorado on February 4, 1985. Also did final assembly on the Cadillac Allante, whose bodies were made in Italy by Pininfarina and were flown to Detroit and then trucked to Detroit/Hamtramck Assembly for final assembly. Started building fwd G-bodies for 1998. The last &lt;br&gt; E-body, the Cadillac Eldorado, was moved to the Lansing Craft Center during 2000. Started building EREVs based on Delta II for 2011. This was followed by the 2nd gen. Volt based on D2XX for 2016. Started building Epsilon-based cars for 2013. Also built the Omega-based Cadillac CT6 flagship, starting with 2016. The last gas-powered vehicles made at this plant were the Cadillac CT6 on January 24, 2020 &amp; the Chevrolet Impala on February 27, 2020. Renamed &quot;Factory ZERO&quot; on October 16, 2020 to reflect its conversion into an electric vehicle assembly plant (zero for zero emissions). First vehicle produced following the conversion was a 2022 GMC Hummer EV pickup on December 17, 2021. Over 4 million vehicles have been built so far since opening in 1985. &lt;br /&gt; Past models:&lt;br&gt; [[w:Oldsmobile Toronado#Fourth generation (1986–1992)|Oldsmobile Toronado]] (1986-1992), [[w:Buick Riviera#Seventh generation (1986–1993)|Buick Riviera]] (1986-1993), [[w:Cadillac Eldorado|Cadillac Eldorado]] (1986-2000), [[w:Cadillac Seville|Cadillac Seville]] (1986-2004), [[w:Cadillac Allanté|Cadillac Allanté]] (1987-1993) (final assembly),&lt;br&gt; [[w:Cadillac Deville|Cadillac Deville]] (1994-2005), [[w:Cadillac DTS|Cadillac DTS]] (2006-2011),&lt;br&gt; [[w:Buick Park Avenue#Second generation (1997–2005)|Buick Park Avenue]] (1998-2000), [[w:Buick LeSabre#Eighth generation (2000–2005)|Buick LeSabre]] (2000-2005), [[w:Buick Lucerne|Buick Lucerne]] (2006-2011), [[w:Pontiac Bonneville#Tenth generation (2000–2005)|Pontiac Bonneville]] (2004-2005), [[w:Chevrolet Volt|Chevrolet Volt]] (2011-2019), [[w:Chevrolet Volt#Other markets|Holden Volt (RE)]] (2012-2015), [[w:Chevrolet Volt#Opel Ampera (Europe)|Opel/Vauxhall Ampera]] (2012-15), [[w:Cadillac ELR|Cadillac ELR]] (2014, 2016), [[w:Chevrolet Malibu#Eighth generation (2013)|Chevrolet Malibu (2013-2015)/Malibu Limited (2016)]], [[w:Chevrolet Impala#Tenth generation (2014-2020)|Chevrolet Impala]] (2014-2020), [[w:Buick LaCrosse#Third generation (2017)|Buick Lacrosse]] (2017-2019), [[w:Cadillac CT6|Cadillac CT6]] (2016-2020)

|-

|&amp;nbsp;||[[w:DMAX (engines)|DMAX Ltd.]]||[[w:Moraine, Ohio|Moraine, Ohio]]||United States||[[w:Duramax V8 engine|Duramax V8 engine]]||2000||&amp;nbsp;||Located on 3100 Dryden Rd. Was a joint venture with [[w:Isuzu|Isuzu]]. Originally, was 40% owned by GM &amp; 60% owned by Isuzu. From 2002, 60% owned by GM &amp; 40% owned by Isuzu. GM bought Isuzu's remaining stake in DMAX Ltd. at the end of March 2022 and DMAX Ltd. became a wholly owned subsidiary of GM in May 2022. 

|- 

|&amp;nbsp;||[[w:DMAX (engines)|DMAX Ltd.]] Components Plant||[[w:Brookville, Ohio|Brookville, Ohio]]||United States||Machined engine components for [[w:Duramax V8 engine|Duramax V8 engine]]||2021||&amp;nbsp;|| Located at 101 W. Campus Blvd. In June 2023, GM announced a $920 million investment to build a 1.1 million square foot building next to the current 251,000 square foot facility in Brookville to take over Duramax V8 engine production from the original plant in Moraine in 2025. 

|-

|&amp;nbsp;||[[w:GM Egypt|GM Egypt]]||[[w:6th of October City|6th of October City]]|| [[w:Egypt|Egypt]]||[[w:Isuzu N-Series|Chevrolet N-Series]]&lt;br/&gt;[[w:Isuzu D-Max#Second generation (RT; 2011)|Chevrolet T-Series]]&lt;br/&gt;[[w:Chevrolet Move#Chevrolet N300/Move|Chevrolet Move]]&lt;br/&gt;[[w:Chevrolet Aveo#Third generation (310C; 2023)|Chevrolet Optra]] (2025-)||1985||&amp;nbsp;||Partially owned by GM (46.5%). Produced its 1 millionth vehicle, a Chevrolet T-Series pickup truck, on September 22, 2024. GM Egypt is the first automaker in Egypt to produce &lt;br&gt; 1 million vehicles. &lt;br /&gt; Past models: [[w:Chevrolet Aveo (T200)|Chevrolet Aveo]], [[w:Chevrolet Captiva#First generation (C100, C140; 2006)|Chevrolet Captiva]], [[w:Chevrolet Frontera|Chevrolet Frontera]], [[w:Chevrolet Lanos|Chevrolet Lanos]], [[w:Baojun 630|Chevrolet Optra]] (2016-2023), [[w:Isuzu D-Max#First generation (RA, RC; 2002)|Chevrolet T-Series]], [[w:Isuzu MU#First generation (UCS55/UCS69GW; 1989–1998)|Isuzu Rodeo]], [[w:Isuzu TF|Isuzu TF-Series]], [[w:Opel Astra|Opel Astra]], [[w:Opel Corsa|Opel Corsa]], [[w:Opel Vectra|Opel Vectra]] 

|- 

|F||[[w:Fairfax II|Fairfax II]]||[[w:Kansas City, Kansas|Kansas City, Kansas]]||United States||[[w:Chevrolet Bolt#Second generation (2026)|Chevrolet Bolt]] (2027)
&lt;br /&gt; [[w:Chevrolet Equinox#Fourth generation (2025)|Chevrolet Equinox]] (Starting Mid-2027)
||1987||&amp;nbsp;||Located at 3201 Fairfax Trafficway. Replaced original Fairfax Assembly Plant (Fairfax I) for 1988 model year production. Built on the site of the old Fairfax Municipal Airport. Originally built W-body cars. Switched to Epsilon-based cars for 2004. Chevy Malibu ended production in November 2024. Cadillac XT4 ended production in January 2025. Fairfax was then idled for retooling. Production of the updated Bolt electric car began in late 2025. The 2027 Bolt is an updated version of the old Bolt EUV. &lt;br /&gt;Past models:  [[w:Pontiac Grand Prix|Pontiac Grand Prix]] (1988-2003), [[w:Oldsmobile Cutlass Supreme#Fifth generation (1988–1997)|Oldsmobile Cutlass Supreme]] (1995-1997), [[w:Oldsmobile Intrigue|Oldsmobile Intrigue]] (1998-'02), [[w:Chevrolet Malibu#Sixth generation (2004)|Chevrolet Malibu (2004-2007)/Malibu Classic (2008)]], [[w:Chevrolet Malibu#Seventh generation (2008)|Chevrolet Malibu (2008-2012)]],&lt;br&gt; [[w:Chevrolet Malibu#Eighth generation (2013)|Chevrolet Malibu (2013-2015)/Malibu Limited (2016)]], [[w:Chevrolet Malibu#Ninth generation (2016)|Chevrolet Malibu (2016-2025)]], &lt;br /&gt;  [[w:Saturn Aura|Saturn Aura]] (2007-2009), [[w:Buick LaCrosse#Second generation (2010)|Buick Lacrosse/Allure]] (2010-2016), [[w:Cadillac XT4|Cadillac XT4]] (2019-2025)

|-

|&amp;nbsp;||[[w:Flint Engine South|Flint Engine South]]||[[w:Flint, Michigan|Flint, Michigan]]||United States|| 3.0 [[w:Duramax I6 engine|Duramax I6 engine]]||2000||&amp;nbsp;||Located at 2100 Bristol Road. Located just to the south of Flint Truck Assembly and on the east side of Flint Metal Center. &lt;br /&gt;Past engines: [[w:GM Atlas engine|4.2 Atlas I6]], 3.6 [[w:GM High Feature engine|High Feature V6 engine]],&lt;br /&gt; 1.4 [[w:GM Family 0 engine#Generation III|Family 0 I4]] (Cruze, Sonic, Volt/Ampera/ELR generator), [[w:GM small gasoline engine#LFV|GM Small Gasoline Engine]] (LFV 1.5 Turbo I4 - Malibu)

|- 

|&amp;nbsp;||[[Flint Metal Center]]||[[w:Flint, Michigan|Flint, Michigan]]||United States|| Sheetmetal stampings for various GM models||1954||&amp;nbsp;||Located at G-2238 Bristol Road. Located just to the south of Flint Truck Assembly and on the west side of Flint Engine South. Metal fabricating plant. 

|- 

|&amp;nbsp;||[[Flint Tool &amp; Die]] (North American Engineering and Tooling Center)||[[w:Flint, Michigan|Flint, Michigan]]||United States||Tools &amp; Dies for fabrication &amp; assembly of sheetmetal body parts||1967||&amp;nbsp;||Located at 425 Stevenson St. Was Plant 38 of the &quot;Chevy in the Hole&quot; complex. Last remaining manufacturing plant of the old &quot;Chevy in the Hole&quot; complex. 

|- 

|F &lt;br/&gt;(1953-present)&lt;br/&gt;&lt;br/&gt; 1 (1947-1952)||[[w:Flint Truck Assembly|Flint Truck Assembly]]||[[w:Flint, Michigan|Flint, Michigan]]||United States||[[w:Chevrolet Silverado|Chevrolet Silverado]] (2001-)&lt;br /&gt; [[w:Chevrolet Silverado|GMC Sierra]] (2001-)||1947||&amp;nbsp;||Located at G 3100 Van Slyke Road. This plant replaced vehicle production at the older &quot;Chevy in the Hole&quot; complex elsewhere in Flint, Michigan and became Chevrolet's new home plant. Began production in June 1947. This is GM's oldest, still active assembly plant in North America. Built all 300 1953 Corvettes on a small makeshift line (1 line for body &amp; 1 for frame/chassis) from June 30 through December 24 in 1953. Built the 50 millionth car built by GM in the US on November 23, 1954. The car was a special gold painted '55 Chevy Bel Air 2-door Sport Coupe with a gold-painted chassis and 716 interior and exterior trim parts plated with 24-carat gold. Last built Chevy full-size cars in 1969. Last built passenger cars in 1970 (the midsize Chevelle &amp; Monte Carlo). The last passenger car built at Flint Assembly was a Monte Carlo on June 24, 1970. At that point, the separate onsite Fisher Body operation (Flint #2) was merged into the Chevrolet operation (the rest of the plant) and the entire plant joined the GM Assembly Division. Since 1971, has only built full-size pickups, full-size SUV's, full-size vans, and medium duty commercial trucks. A new paint shop (Flint Assembly Paint Operations) was announced in December 2013 and opened in 2016, replacing the previous paint shop located inside the assembly plant. The new paint shop is further down Van Slyke Road from the assembly plant at 3848 Van Slyke Road, on the site of the former V8 engine plant that closed in 1999 and was subsequently demolished. Flint Truck Assembly has produced over 15 million vehicles. &lt;br /&gt;Past models:  [[w:Chevrolet Deluxe|Chevrolet Deluxe]], [[w:Chevrolet Stylemaster|Chevrolet Stylemaster]], [[w:Chevrolet Fleetmaster|Chevrolet Fleetmaster]], [[w:Chevrolet 150|Chevrolet 150]] (1953-1957),&lt;br&gt; [[w:Chevrolet 210|Chevrolet 210]] (1953-1957), [[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1950-1969), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1958-69), [[w:Chevrolet Impala|Chevrolet Impala]] (1958-1969), [[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-69), [[w:Chevrolet Nomad|Chevrolet Nomad]] (1955-1957), [[w:Chevrolet Corvette (C1)|Chevrolet Corvette (1953 only)]]&lt;br&gt; [[w:Chevrolet El Camino#First generation (1959–1960)|Chevrolet El Camino]] (1959-1960),&lt;br&gt; [[w:Chevrolet Chevelle|Chevrolet Chevelle]] (1966, 1970),&lt;br&gt; [[w:Chevrolet Monte Carlo|Chevrolet Monte Carlo]] (1970 only),&lt;br&gt;  [[w:Chevrolet K5 Blazer|Chevrolet K5 Blazer]] (1969-1991), [[w:Chevrolet K5 Blazer|GMC K15 Jimmy]] (1970-91), [[w:Chevrolet Suburban|Chevrolet Suburban]] (1960-1991), [[w:GMC Suburban|GMC Suburban]] (1967-91),&lt;br&gt; [[w:Chevrolet Corvair|Chevrolet Corvair Forward Control]] (1961-1964), &lt;br&gt; [[w:Chevrolet van#Third generation (1971-1996)|Chevrolet Van/Sportvan]] (1993-1995),&lt;br&gt; [[w:Chevrolet van#1992-1996|Chevrolet Van/Sportvan G-Classic]] (1996),&lt;br&gt; [[w:Chevrolet van#Third generation (1971-1996)|GMC Vandura/Rally Van]] (1993-1995),&lt;br&gt; [[w:Chevrolet van#1992-1996|GMC Vandura/Rally Van G-Classic]] (1996),&lt;br&gt; [[w:Chevrolet Advance Design|Chevrolet Advance Design]] (1947-1955), [[w:Chevrolet Task Force|Chevrolet Task Force]] (1955-1959), [[w:Chevrolet C/K|Chevrolet C/K]] (1960-1986), [[w:Chevrolet C/K (second generation)|GMC C/K (Action Line)]] (1967-1972), [[w:Chevrolet C/K (third generation)|GMC C/K (Rounded Line)]] (1973-1986), [[w:Chevrolet C/K (third generation)#R/V-Series (1987–1991)|Chevrolet R/V]] (1987-1991), [[w:Chevrolet C/K (third generation)#R/V-Series (1987–1991)|GMC R/V]] (1987-1991), [[w:Chevrolet C/K (fourth generation)|Chevrolet C/K (GMT400)]] (1995-2000), [[w:Chevrolet C/K (fourth generation)|GMC Sierra (GMT400)]] (1995-98), [[w:Chevrolet C/K (fourth generation)|GMC Sierra Classic (GMT400)]] (1999-2000), [[w:Chevrolet C/K (fourth generation)#C3500HD (1991–2002)|Chevrolet/GMC C3500HD]] (1998-00), [[w:Chevrolet Kodiak#Third generation (2003–2009)|Chevrolet Kodiak/GMC Topkick]] ('03-'09), [[w:Chevrolet Kodiak#Isuzu H-Series|Isuzu H-Series]] (2005-2007), [[w:Isuzu Forward|Chevrolet T-Series]] (2004-2009), [[w:GMC T-Series|GMC T-Series]] (2004-2009), [[w:Isuzu F-Series|Isuzu F-Series]] (2004-2009) &lt;br /&gt; 

|- 

|Z||[[w:Fort Wayne Assembly|Fort Wayne Assembly]]||[[w:Roanoke, Indiana|Roanoke, Indiana]]||United States||[[w:Chevrolet Silverado|Chevrolet Silverado]] (1999-)&lt;br /&gt;[[w:Chevrolet Silverado|GMC Sierra]] (1988-)||1986||&amp;nbsp;||Located at 12200 Lafayette Center Rd.&lt;br /&gt; Past models: [[w:Chevrolet C/K (fourth generation)|Chevrolet C/K]] (1988-1998)

|-

|&amp;nbsp;||[[Fuel Cell System Manufacturing LLC]]||[[w:Brownstown Charter Township, Michigan|Brownstown Charter Township, Michigan]]||United States||Fuel Cell Systems for [[w:Honda CR-V#CR-V e:FCEV|Honda CR-V e:FCEV]] &amp; various other applications by GM &amp; Honda &amp; to outside companies||2024||&amp;nbsp;||Located at 20001 Brownstown Center Dr. Located next to GM's Brownstown Battery Assembly Plant.&lt;br /&gt; A 50/50 joint venture with [[w:Honda|Honda]]. GM &amp; Honda have been co-developing fuel cells since 2013. The manufacturing joint venture was established in January 2017. Production began in January 2024. Production is scheduled to end by the end of 2026.
 
|-

|&amp;nbsp;||Grand Rapids Operations||[[w:Wyoming, Michigan|Wyoming, Michigan]]||United States||Valvetrain products &lt;br /&gt; Axles for full-size trucks ||1943||&amp;nbsp;||Located at 2100 Burlingame Avenue SW. Originally established as Diesel Equipment Division of GM. Spun off with Delphi Automotive Systems in 1999 (Delphi Powertrain Systems Grand Rapids); taken back under [[w:Delphi Corporation|Delphi Corporation]] bankruptcy and made part of [[w:General Motors Components Holdings|General Motors Components Holdings]] in 1999. 

|- 

|G||[[w:General Motors do Brasil|Gravatai Automotive Industrial Complex]]||[[w:Gravatai|Gravatai]], [[w:Rio Grande do Sul|Rio Grande do Sul]]||[[w:Brazil|Brazil]]||[[w:Chevrolet Onix|Chevrolet Onix]]&lt;br /&gt; ||2000||&amp;nbsp;||Past models: [[w:Chevrolet Celta|Chevrolet Celta]]&lt;br /&gt;[[w:Chevrolet Prisma (disambiguation)|Chevrolet Prisma]]&lt;ref&gt;{{cite web|url=http://www.autointell.com/nao_companies/general_motors/gm-manufacturing/blue-macaw-01.htm|title=General Motors: Gravatai Automotive Complex|access-date=2021-09-14 }}&lt;/ref&gt;&lt;ref&gt;[https://www.reuters.com/article/idUSN1533675720090715 UPDATE 2-GM to spend $1 bln in Brazil on new family of cars] Retrieved 14 September 2021&lt;/ref&gt;&lt;br /&gt; [[w:Suzuki Fun|Suzuki Fun]] 

|- 

|&amp;nbsp;||[[Joinville]]||[[w:Joinville|Joinville]], [[w:Santa Catarina (state)|Santa Catarina]]||[[w:Brazil|Brazil]]||[[w:GM E-Turbo engine|1.0 &amp; 1.0 Turbo 3-cylinder engine]]&lt;br /&gt;[[w:GM E-Turbo engine|1.2 &amp; 1.2 Turbo 3-cylinder engine]] ||2013||&amp;nbsp;||Past engines: [[w:GM Family 1 engine#SPE / 4|1.0L &amp; 1.4L SPE / 4&lt;br /&gt; 4-cylinder engines]] 

|- 

|&amp;nbsp;||Kokomo Operations&lt;ref&gt;{{Cite web|url=https://plants.gm.com/media/us/en/gm/company_info/facilities/component-fac/kokomo.html|title=GM Corporate Newsroom - United States - Company}}&lt;/ref&gt;||[[w:Kokomo, Indiana|Kokomo, Indiana]]||United States||Automotive Electronic Components including Engine Control Modules, Transmission Control Modules, Body Control Modules, &amp; Airbag Sensing Diagnostic Modules||1936||&amp;nbsp;||Located at 2603 South Goyer Rd. The site was first used in the 1890's to make cars by [[w:Haynes-Apperson|Haynes-Apperson]] and later by [[w:Haynes Automobile Company|Haynes]] until the company went out of business in 1925. Purchased by GM in 1936 from Crosley Radio Corp., which used the site to make radios for Chevrolet briefly during 1936. Initially run by Delco Remy, the site became a separate GM division called Delco Radio Division in June 1936. Delco Radio made radios for all GM cars as well as other electronic equipment. During WWII, Delco Radio made electronic equipment for the war effort. In 1970, Delco Radio merged with AC Electronics Division of Milwaukee to form [[w:Delco Electronics|Delco Electronics Division]]. On December 31, 1985, General Motors merged Hughes Aircraft, which it had acquired on December 20, 1985, with its Delco Electronics unit to form Hughes Electronics Corporation, an independent subsidiary. The group then consisted of Delco Electronics Corporation and Hughes Aircraft Company. In 1997, GM transferred Delco Electronics to its Delphi Automotive Systems business. Spun off with Delphi Automotive Systems in 1999 (Delco Electronics and Safety); taken back under [[w:Delphi Corporation|Delphi Corporation]] bankruptcy and made part of [[w:General Motors Components Holdings|General Motors Components Holdings]] in 2009. 

|-

| ||[[w:GM Korea|GM Korea]]||[[w:Boryeong|Boryeong]], [[w:South Chungcheong Province|South Chungcheong Province]]||[[w:South Korea|South Korea]]||Automatic Transmissions||2008||&amp;nbsp;||[[w:GM 6T40 transmission|GM 6T40 transmission]] (GF6) 

|- 

|B&lt;br /&gt;&lt;br /&gt;0 ('07-'08 Antara)||[[w:GM Korea|GM Korea]]||[[w:Bupyeong-gu|Bupyeong District]], [[w:Incheon|Incheon]]||[[w:South Korea|South Korea]]||[[w:Chevrolet Trailblazer (crossover)|Chevrolet Trailblazer]]&lt;br/&gt;[[w:Buick Encore GX|Buick Encore GX]]&lt;br/&gt;[[w:Buick Envista|Buick Envista]] 

 
Engines: [[w:GM Family 0 engine|GM Family 0 engine]]&lt;br /&gt;[[w:GM E-Turbo engine|1.3L Turbo 3-cylinder engine]] 

|1962&lt;br /&gt;&lt;br/&gt;1971 (engine plant)||&amp;nbsp;||Bupyeong has 2 vehicle assembly plants and a powertrain plant. The Bupyeong 2 Assembly Plant ended production on November 26, 2022. Bupyeong 2 was last producing the Chevrolet Malibu and Trax and Buick Encore.&lt;br /&gt;Past models : [[w:Chevrolet Aveo|Chevrolet Aveo]], [[w:Chevrolet Sonic|Chevrolet Sonic]], [[w:Chevrolet Captiva|Chevrolet Captiva]], [[w:Chevrolet Epica|Chevrolet Epica]], [[w:Chevrolet Evanda|Chevrolet Evanda]], [[w:Chevrolet Malibu|Chevrolet Malibu]], [[w:Chevrolet Trax#First generation (U200; 2013)|Chevrolet Trax]]&lt;br /&gt; 

[[w:Buick Encore#First generation (2013)|Buick Encore]]&lt;br /&gt; 


[[w:Buick LaCrosse#Korean market: Alpheon|Alpheon]] 
 

[[w:Daewoo LeMans|Daewoo LeMans]], [[w:Daewoo Cielo|Daewoo Cielo]], [[w:Daewoo Espero|Daewoo Espero]], [[w:Daewoo Lanos|Daewoo Lanos]], [[w:Daewoo Leganza|Daewoo Leganza]], [[w:Daewoo Magnus|Daewoo Magnus]], [[w:Daewoo Tosca|Daewoo Tosca]], [[w:Daewoo Kalos|Daewoo Kalos]], [[w:Chevrolet Aveo (T200)#T250|Daewoo Gentra]], [[w:Daewoo Winstorm|Daewoo Winstorm]] 
 

[[w:Holden Barina#Fifth generation (TK; 2005–2011)|Holden Barina (TK)]], [[w:Holden Barina#Sixth generation (TM; 2011–2018)|Holden Barina (TM)]], [[w:Opel Antara|Holden Captiva MaXX/Captiva 5]], [[w:Chevrolet Captiva#First generation (C100, C140; 2006)|Holden Captiva/Captiva 7]], [[w:Holden Epica|Holden Epica (EP)]], [[w:Chevrolet Malibu#Eighth generation (2013)|Holden Malibu (EM)]], [[w:Chevrolet Trax#First generation (U200; 2013)|Holden Trax (TJ)]] &lt;br /&gt;  
 

[[w:Opel Antara|GMC Terrain (Middle East only)]] &lt;br /&gt;  

[[w:Opel Mokka#First generation (J13; 2012)|Opel/Vauxhall Mokka]], [[w:Opel Antara|Opel/Vauxhall Antara]]&lt;br /&gt; 

[[w:Pontiac LeMans#Sixth generation (1988–1993)|Pontiac LeMans]], [[w:Pontiac Wave|Pontiac Wave]], [[w:Pontiac G3|Pontiac G3]] &lt;br /&gt; 

[[w:Suzuki Swift+|Suzuki Swift+]] (Canada only), [[w:Suzuki Verona|Suzuki Verona]] 

 
Past engines: [[w:GM Family 1 engine|GM Family 1 engine]]  

|- 

|C||[[w:GM Korea|GM Korea]]||[[w:Changwon|Changwon]], [[w:Gyeongsang Province|Gyeongsang Province]]||[[w:South Korea|South Korea]]||[[w:Chevrolet Trax#Second generation (2023)|Chevrolet Trax]]&lt;br/&gt;[[w:GM small gasoline engine|GM small gasoline engine]] LV7, LE2&lt;br/&gt;Manual transmissions 

|1991||&amp;nbsp;||Past models: [[w:Daewoo Damas|Damas]], [[w:Daewoo Labo|Labo]]&lt;br /&gt;[[w:Daewoo Matiz|Daewoo Matiz]], [[w:Daewoo Tico|Daewoo Tico]]&lt;br /&gt;[[w:Opel Karl|Opel Karl]]/[[w:Vauxhall Viva#Name revival|Vauxhall Viva]]&lt;br /&gt;[[w:Pontiac G2#Second generation (M200, M250; 2005)|Pontiac G2]], [[w:Pontiac Matiz#M150 (2000–2005)|Pontiac Matiz]],&lt;br /&gt; [[w:Chevrolet Spark|Chevrolet Spark]], [[w:Chevrolet Spark#Spark EV|Chevrolet Spark EV]]&lt;br /&gt;[[w:Holden Spark#Australasia|Holden Barina Spark (MJ)]]&lt;br&gt;[[w:Holden Spark|Holden Spark (MP)]]

 
Past engines: [[w:Daewoo S-TEC engine#S-TEC II|Daewoo S-TEC II]] 

|-

|J||[[w:Lansing Delta Township Assembly|Lansing Delta Township Assembly]]||[[w:Delta Township, Michigan|Delta Township, Michigan]]||United States||[[w:Chevrolet Traverse|Chevrolet Traverse]] (2010-)&lt;br /&gt;[[w:Buick Enclave|Buick Enclave]] (2008-)&lt;br /&gt;[[w:GMC Acadia#Third generation (2024)|GMC Acadia]] (2024-)||2006||&amp;nbsp;||Located at 8175 Millett Hwy. Originally opened to build Lambda-based crossovers. Switched to C1XX-based models for 2018. &lt;br /&gt; Past models: [[w:Saturn Outlook|Saturn Outlook]] (2007-2010),&lt;br&gt;[[w:GMC Acadia#First generation (2007)|GMC Acadia]] (2007-2016), [[w:GMC Acadia#Acadia Limited|GMC Acadia Limited]] (2017), &lt;br&gt;[[w:Chevrolet Traverse#Second generation (2018)|Chevrolet Traverse Limited]] (2024)

|- 

|0||[[w:Lansing Grand River Assembly|Lansing Grand River Assembly]]/Stamping||[[w:Lansing, Michigan|Lansing, Michigan]]||United States||[[w:Cadillac CT4|Cadillac CT4]] (2020-)&lt;br /&gt;[[w:Cadillac CT5|Cadillac CT5]] (2020-)||2001||&amp;nbsp;||Located at 920 Townsend Street. Stamping plant added in 2016. This newly constructed plant was built on the grounds of the former Oldsmobile home plant complex in Lansing. The former Oldsmobile HQ building (&quot;Building 70&quot;) is still standing and still has &quot;Oldsmobile Administration Center&quot; carved into the marble barrier in front of the flagpole between the 2 stairways. Building 70 was Oldsmobile HQ from 1966-1996, when Oldsmobile HQ moved to Detroit. Building 70 is now vacant but the exterior is often used by GM for large ads that are wrapped around the side of the building on the corner of Townsend St. and William St. Originally opened to build vehicles on the Sigma platform. Started building vehicles on the Alpha platform for 2013.&lt;br /&gt; Past models: [[w:Cadillac CTS|Cadillac CTS]] (2003-2019), [[w:Cadillac SRX#First generation (2004)|Cadillac SRX]] (2004-2009), [[w:Cadillac STS|Cadillac STS]] (2005-2011), [[w:Cadillac ATS|Cadillac ATS]] (2013-2019), [[w:Chevrolet Camaro (sixth generation)|Chevrolet Camaro]] (2016-2024)

|- 

|&amp;nbsp;||[[Lansing Regional Stamping]] (LRS)||[[w:Delta Township, Michigan|Delta Township, Michigan]]||United States||&amp;nbsp;||2004|| ||Located within the Lansing Delta Assembly complex.  

|- 

|||[[w:Lansing Service Parts Operation|Lansing Redistribution Center]] (SPO)||[[w:Delta Township, Michigan|Delta Township, Michigan]]||United States||&amp;nbsp;||1960|| ||Located at 4400 West Mount Hope Road. Previously Lansing Plant 4. Now called Lansing Redistribution Center, part of GM Customer Care and Aftersales.  

|-

|&amp;nbsp;||[[Lockport Operations]]||[[w:Lockport, NY|Lockport, NY]]||United States||Thermal products (climate control systems, powertrain cooling systems) and stators for EV motors.||1914||&amp;nbsp;||Located at 200 Upper Mountain Road. Founded in 1910 as the Harrison Radiator Company. Acquired by United Motors in 1916 which was then acquired by GM in 1918. Spun off with Delphi Automotive Systems in 1999 (Harrison Thermal Systems); taken back under [[w:Delphi Corporation|Delphi Corporation]] bankruptcy and made part of [[w:General Motors Components Holdings|General Motors Components Holdings]] in 2009. 

|- 

|&amp;nbsp;||[[Marion Metal Center]]||[[w:Marion, Indiana|Marion, Indiana]]||United States||Sheetmetal stamped parts &amp; blanks for various GM models||1956||&amp;nbsp;||Located at 2400 West Second St. Metal fabricating. Originally a Fisher Body division plant.  

|- 

|&amp;nbsp;||[[Mogi das Cruzes]]||[[w:Mogi das Cruzes|Mogi das Cruzes]], [[w:São Paulo (state)|São Paulo state]]||[[w:Brazil|Brazil]]||Stampings for new &amp; replacement parts||1999||&amp;nbsp;||Stamping plant 

|-

|4||[[w:Orion Assembly|Orion Assembly]]||[[w:Orion Township, Michigan|Orion Township, Michigan]]||United States||Assembly of Battery packs for EVs:&lt;br&gt; Silverado EV, Sierra EV, Hummer EV, and Escalade IQ&lt;br&gt;&lt;br&gt;Scheduled for Early 2027:
[[w:Chevrolet Silverado|Chevrolet Silverado]] 1500 (2027-)&lt;br /&gt;[[w:GMC Sierra|GMC Sierra]] 1500 (2027-) 
||1983||idled 2009; reopened 2011; idled 2023||Located at 4555 Giddings Road. Originally opened to build the 1985 Fwd C-bodies. Began building Fwd H-bodies for 1994. Began building Fwd G-bodies for 1995. On June 18, 2004, production of the Buick LeSabre &amp; Park Ave., the last 2 models built at Orion Assembly, ended. Plant was then converted from building full-size cars to midsize cars for 2005, beginning with the Pontiac G6. Idled during 2009 as part of GM's bankruptcy. Reopened in 2011 with the help of govt. incentives &amp; special agreement with the UAW to build the Chevy Sonic subcompact. Later added the Buick Verano compact car. In 2016, began building the Chevy Bolt EV, which was joined in 2021 by the slightly larger Bolt EUV. Idled in 2023 when both Bolts were discontinued. In late summer 2024, Orion Assembly began assembling battery cells supplied by Ultium Cells LLC in Warren, OH into packs which are then supplied to the Factory Zero plant for installation into the electric trucks &amp; SUVs made there. Orion was going to be converted to building electric trucks, supplementing Factory Zero's production of Silverado EV &amp; Sierra EV but that plan was postponed and later cancelled. In 2025, a new plan was announced for Orion to build fuel-powered Silverado &amp; Sierra 1500 pickups &amp; Escalade SUVs beginning in 2027.&lt;br&gt; Past models: [[w:Chevrolet Bolt EV|Chevrolet Bolt EV]] (2017-2023), [[w:Chevrolet Bolt EUV|Chevrolet &lt;br&gt; Bolt EUV]] (2022-2023), [[w:Cruise AV|Cruise AV]], [[w:Chevrolet Bolt#European countries|Opel Ampera-e]] (2017-19),&lt;br&gt; [[w:Chevrolet Sonic|Chevrolet Sonic]] (2012-2020), [[w:Buick Verano#First generation (2011)|Buick Verano]] (2012-2017), [[w:Chevrolet Malibu#Seventh generation (2008)|Chevrolet Malibu]] (2008-2010), [[w:Pontiac G6|Pontiac G6]] (2005-2010),&lt;br&gt; [[w:Buick Riviera#Eighth generation (1995–1999)|Buick Riviera]] (1995-1999), [[w:Oldsmobile Aurora|Oldsmobile Aurora]] (1995-2003),&lt;br&gt; [[w:Buick Park Avenue#Second generation (1997-2005)|Buick Park Avenue]] (1997-2005), [[w:Buick LeSabre#Eighth generation (2000–2005)|Buick LeSabre]] (2000-2005), [[w:Cadillac de Ville series#Sixth generation (1985–1993)|Cadillac DeVille]] (1985-1993), [[w:Cadillac Fleetwood#Front-wheel drive: 1985–1993|Cadillac Fleetwood]] (1985-1992), [[w:Cadillac Sixty Special#1987–1993|Cadillac Sixty Special]] (1989-1993), [[w:Oldsmobile 88#Tenth generation (1992–1999)|Oldsmobile 88]] (1994-99), [[w:Oldsmobile LSS|Oldsmobile LSS]] (1996-1999), [[w:Oldsmobile Regency|Oldsmobile Regency]] (1997-98), [[w:Oldsmobile 98#Eleventh generation (1985–1990)|Oldsmobile 98]] (1985-1990), [[w:Oldsmobile 98#Twelfth generation (1991–1996)|Oldsmobile 98]] (1991-1996), [[w:Oldsmobile Touring Sedan|Oldsmobile Touring Sedan]] (1988-1990),&lt;br&gt; [[w:Pontiac Bonneville#Ninth generation (1992–1999)|Pontiac Bonneville]] (1994-1998), [[w:Pontiac Bonneville#Tenth generation (2000–2005)|Pontiac Bonneville]] (2000-03)

|- 

|1 (2022-)&lt;br /&gt;&lt;br /&gt;1 (Line 2 a.k.a. Consolidated Line)&lt;br&gt; (1984-2019)&lt;br&gt;/&lt;br /&gt;9 (Line 1 a.k.a. Flex Line)&lt;br&gt; (1984-2020)&lt;br /&gt;&lt;br /&gt;1 (1967-1983)||[[w:Oshawa Car Assembly|Oshawa Car Assembly]]||[[w:Oshawa, Ontario|Oshawa, Ontario]]||[[w:Canada|Canada]]||[[w:Chevrolet Silverado#Fourth-generation Silverado / fifth-generation Sierra (T1XX; 2019)|Chevrolet Silverado 1500]] (2022-)&lt;br /&gt;[[w:Chevrolet Silverado#Fourth-generation Silverado / fifth-generation Sierra (T1XX; 2019)|Chevrolet Silverado HD]] (2022-)||1953||&amp;nbsp;||Located at 900 Park Rd South.&lt;br /&gt; 
Past models: [[w:Cadillac XTS|Cadillac XTS]] (2013-2019), [[w:Chevrolet Impala|Chevrolet Impala]] (1958-1985, 2000-2020), [[w:Chevrolet Impala#Impala Limited (2014–2016)|Chevrolet Impala Limited]] (2014-2016), [[w:Chevrolet Lumina|Chevrolet Lumina]] (1990-2001), [[w:Chevrolet Monte Carlo|Chevrolet Monte Carlo]] (1995-2007), [[w:Buick Century#Sixth generation (1997–2005)|Buick Century]] (1997-2005), [[w:Buick Regal|Buick Regal]] (1988-2004, 2011-2017), [[w:Buick LaCrosse#First generation (2005)|Buick LaCrosse/Allure]] (2005-2009), [[w:Buick Special#1949–1958|Buick Special]] (1954-1958), [[w:Buick LeSabre|Buick LeSabre]] (1959-1966), [[w:Buick Century#Second generation (1954–1958)|Buick Century]] (1954-1958), [[w:Buick Invicta|Buick Invicta]] (1959-1962), [[w:Buick Wildcat|Buick Wildcat]] (1963-1966), [[w:Oldsmobile 88|Oldsmobile 88]] (1954-1966), [[w:Chevrolet 150|Chevrolet 150]] (1954-1957), [[w:Chevrolet 210|Chevrolet 210]] (1954-1957), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1955-1981), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1958-1975), [[w:Chevrolet Camaro (fifth generation)|Chevrolet Camaro]] (2010-2015), [[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-1985), [[w:Chevrolet Corvair|Chevrolet Corvair]] (1960-1966), [[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958), [[w:Chevrolet Equinox#Second generation (2010)|Chevrolet Equinox]] (2011-2017), [[w:Chevrolet Nova|Chevrolet Nova]] (1962-1967),&lt;br&gt; [[w:General Motors A platform (1925)#1964|A-body (rwd) cars]]: [[w:Chevrolet Chevelle|Chevrolet Chevelle]] (1964-1977)/[[w:Chevrolet Malibu|Chevrolet Malibu]] (1978-1983)/[[w:Chevrolet Monte Carlo|Chevrolet Monte Carlo]] (1971-1981)/ [[w:Oldsmobile Cutlass|Oldsmobile Cutlass]]/[[w:Oldsmobile 442|Oldsmobile 442]]/[[w:Pontiac LeMans|Pontiac LeMans]] (1971, 1973-1981)/[[w:Pontiac GTO|Pontiac GTO]] (1970)/[[w:Buick Special|Buick Special]]/[[w:Buick Skylark|Buick Skylark]],&lt;br&gt; [[w:General Motors A platform (1982)|A-body (fwd) cars]]: [[w:Chevrolet Celebrity|Chevrolet Celebrity]] (1982-1987)/[[w:Pontiac 6000|Pontiac 6000]] (1982-1988)/[[w:Oldsmobile Cutlass Ciera|Oldsmobile Cutlass Ciera]] (1985-1988),&lt;br&gt;  [[w:Pontiac Bonneville#Sixth generation (1977–1981)|Pontiac Bonneville]] (1977-1981), [[w:Pontiac Catalina#1977–1981|Pontiac Catalina]] (1977-1981), [[w:Pontiac Grand Prix#Eighth generation (2004–2008)|Pontiac Grand Prix]] (2004-2008), [[w:Pontiac Catalina#Canada and Canadian exports|Pontiac Laurentian]] (1954-1981), [[w:Pontiac Parisienne|Pontiac Parisienne]] (1958-1984, US: 1983-1984), [[w:Pontiac Pathfinder|Pontiac Pathfinder]] (1954-1958), [[w:Pontiac Catalina#Canada and Canadian exports|Pontiac Strato Chief]] (1958-1970), [[w:Acadian (automobile)|Acadian]] (1962-1967), [[w:Beaumont (automobile)|Beaumont]] (1966-1969),  [[w:Chevrolet Silverado#Third-generation Silverado / fourth-generation Sierra (K2XX; 2014)|Chevrolet Silverado 1500 LD/2500HD]] (2019), [[w:Chevrolet Silverado#Third-generation Silverado / fourth-generation Sierra (K2XX; 2014)|GMC Sierra 1500 Limited/2500HD]] (2019). &lt;br /&gt; 

VIN code 1 (1984-2019): Chevrolet Celebrity (1984-1987), Pontiac 6000 (1984-1985), Buick Regal (1988-2004), Chevrolet Lumina 4-d (1990-2001), Buick Century (1997-05), Pontiac Grand Prix (2004-2008), Buick LaCrosse/Allure (2005-2009), Chevrolet Impala (2008-2013), Chevrolet&lt;br /&gt; Impala Limited (2014-2016), Chevrolet Equinox (2011-2017), Chevrolet Silverado 1500 LD/2500HD (2019),&lt;br /&gt; GMC Sierra 1500 Limited/2500HD (2019)

VIN code 9: Chevrolet Impala (1984-1985), Chevrolet Caprice (1984-1985), Pontiac Parisienne (1984), Pontiac 6000 (1985-1988), Oldsmobile Cutlass Ciera (1985-1988), Chevrolet Lumina 4-d (1990-1999),  Chevrolet Lumina 2-d (1990-1994), Chevrolet Monte Carlo (1995-07), Chevrolet Impala (2000-08), Chevrolet Camaro (2010-2015), Buick Regal (2011-2017), Cadillac XTS (2013-2019), Chevrolet Impala (2014-2020) 

The current Oshawa complex (South plant; also known as Autoplex beginning in the 1980's) opened on November 7, 1953. The passenger car assembly plant had 2 assembly lines.  Operations were gradually moved from the older North plant to the newer South plant. Originally built Chevrolet, Pontiac, Oldsmobile, and Buick models. However, Oldsmobile production ended in 1969 and Buick production ended in 1971. Oldsmobile production resumed with the '85 Cutlass Ciera while Buick production resumed with the '88 Regal. Oldsmobile production again ended in 1988 while Buick production continued through 2017 with a temporary hiatus in 2009-2010 calendar years. Pontiac production at Oshawa ended after 1988; only resuming in 2003 for the '04 Grand Prix. Pontiac production at Oshawa ended for good in 2008. Cadillac production began at the Oshawa South plant for the first time in 2012 with the 2013 XTS. Full-size pickups were built on Line 2 for 2019. This was the first time that pickups were built on one of Oshawa's passenger car assembly lines and the first time that pickups were made in Oshawa since Oshawa Truck closed in 2009. The last XTS was built on Sept. 10, 2019, the last Oshawa-built Impala on Oct. 25, 2019, &amp; the last pickups on Dec. 18, 2019. Vehicle production at the South plant ended in 2019; plant will be transformed for stamping and production of body panels and subassemblies. Restart of vehicle production announced in Nov. 2020 - Truck production started in late 2021 with Silverado HD followed by the Silverado 1500 in 2022. Oshawa is now the only plant producing both Silverado 1500 &amp; Silverado HD.

Oshawa also produced face masks during the COVID-19 pandemic starting in 2020.

|- 

|&amp;nbsp;||[[w:Oshawa Metal|Oshawa Metal]]||[[w:Oshawa, Ontario|Oshawa, Ontario]]||[[w:Canada|Canada]]||Stamped metal parts for new production and for service parts||1986||&amp;nbsp;||Part of the overall Oshawa Assembly complex (Autoplex) on Park Road South. Located at 1000 Park Road South. 

|-

|&amp;nbsp;||[[w:Parma Metal Center|Parma Metal Center]]||[[w:Parma, Ohio|Parma, Ohio]]||United States||Sheetmetal stampings &amp; assemblies for various GM models||1948||&amp;nbsp;||Located at 5400 Chevrolet Blvd.&lt;br /&gt; Metal fabricating 

|- 

|&amp;nbsp;||[[Pontiac Metal Center]]||[[w:Pontiac, Michigan|Pontiac, Michigan]]||United States||Sheetmetal stampings &amp; assemblies for various GM models||1926||&amp;nbsp;||Located at 260 E. Beverly Ave.&lt;br /&gt;Metal fabricating&lt;br /&gt;Originally, an [[w:Oakland Motor Car Company|Oakland Motor Car]] plant. Last remaining manufacturing plant of the original Pontiac Assembly complex, which was Pontiac's home plant. 

|-

|S||[[w:Ramos Arizpe Assembly|Ramos Arizpe Assembly]]||[[w:Ramos Arizpe|Ramos Arizpe]]||[[w:Mexico|Mexico]]||[[w:Chevrolet Blazer (crossover)|Chevrolet Blazer]] (2019-) &lt;br /&gt;[[w:Chevrolet Blazer EV|Chevrolet Blazer EV]] (2024-) &lt;br /&gt; [[w:Chevrolet Equinox EV|Chevrolet Equinox EV]] (2024-) &lt;br /&gt;[[w:Cadillac Optiq|Cadillac Optiq EV]] (2025-)&lt;br /&gt; [[w:Honda Prologue|Honda Prologue EV]] (2024-) ||1981||&amp;nbsp;||Ramos Arizpe opened building 4 Chevrolet models for the Mexican market: Citation, Celebrity, Malibu, and Monte Carlo. The 1985 El Camino &amp; Caballero were the first Mexican-built GM models to be sold in the US. GM began exporting the Celebrity to the US for 1987 followed by the Buick Century for 1989. GM began exporting the Chevy Cavalier to the US for 1991 followed by the Pontiac Sunbird for 1993, which was replaced by the Sunfire for 1995. Stamping plant added in 1995 and a paint shop added in 1997. The plant was expanded to add a 2nd assembly line to build the Pontiac Aztek for 2001, followed by the Buick Rendezvous for 2002. The 2nd line was also used to build the Chevy HHR, Saturn Vue, Chevy Captiva Sport, Cadillac SRX, &amp; Saab 9-4X. Some 2nd gen. Chevy Cruze sedans made at Ramos Arizpe were sold in the US for the '16-'17 model years. All 2nd gen. Chevy Cruze 5-d hatchbacks ('17-'19) were made in Ramos Arizpe. All Chevy Cruze production at Ramos Arizpe ended in &lt;br&gt; Dec. 2018. The Cruze was the last passenger car made at Ramos Arizpe. A new paint shop was added in 2021, replacing the original from 1997. EV production began in 2023.&lt;br /&gt;Past Models: &lt;br&gt; Mexico or Latin America only: [[w:Chevrolet Citation|Chevrolet Citation]] (1982-1986), [[w:Chevrolet Celebrity|Chevrolet Celebrity]] (1982-1986), [[w:Chevrolet Malibu#Fourth generation (1978)|Chevrolet Malibu]] (1981), [[w:Chevrolet Monte Carlo#Fourth generation (1981–1988)|Chevrolet Monte Carlo]] (1981-1984), [[w:Oldsmobile Cutlass Ciera|Chevrolet Cutlass (Mexico only)]], [[w:Buick Century#Fifth generation (1982–1996)|Chevrolet Century (Mexico only)]], [[w:Chevrolet Chevy|Chevrolet Chevy]] (Mexico: 1995-2012), [[w:Chevrolet Captiva Sport|Chevrolet Captiva Sport]] (2008-2017), [[w:Chevrolet Sonic|Chevrolet Sonic]] (Mexico: 2012-2017).&lt;br&gt; Export to US: [[w:Chevrolet El Camino|Chevrolet El Camino]] (1985-1987), [[w:GMC Caballero|GMC Caballero]] (1985-1987), [[w:Chevrolet Celebrity|Chevrolet Celebrity]] (US: 1987-1989), [[w:Buick Century#Fifth generation (1982–1996)|Buick Century]] (1989-1994), [[w:Chevrolet Cavalier|Chevrolet Cavalier]] (1991-2004), [[w:Pontiac Sunbird#Second generation (1982–1988)|Pontiac Sunbird]] (1993-1994), [[w:Pontiac Sunfire|Pontiac Sunfire]] (1995-2005), [[w:Pontiac Aztek|Pontiac Aztek]] (2001-2005), [[w:Buick Rendezvous|Buick Rendezvous]] (2002-2007), [[w:Chevrolet HHR|Chevrolet HHR]] (2006-2011), [[w:Saturn Vue#Second generation (2008)|Saturn Vue]] (2008-2010), [[w:Chevrolet Captiva Sport|Chevrolet Captiva Sport]] (US: 2012-2015), [[w:Cadillac SRX#Second generation (2010)|Cadillac SRX]] (2010-2016), [[w:Saab 9-4X|Saab 9-4X]] (2011), [[w:Chevrolet Cruze#Second generation (J400)|Chevrolet Cruze]] (2016-2019), [[w:Chevrolet Equinox#Third generation (2018)|Chevrolet Equinox]] (2018-2024).&lt;br&gt; Export to Australia/New Zealand: [[w:Holden Equinox|Holden Equinox (EQ)]] (2018-2020)

|- 

|&amp;nbsp;||Ramos Arizpe Engine||[[w:Ramos Arizpe|Ramos Arizpe]]||[[w:Mexico|Mexico]]||[[w:GM E-Turbo engine|1.2L Turbo 3-cylinder engine]]&lt;br /&gt;[[w:General Motors LS-based small-block engine#Generation V (2013–present)|Gen V Small Block V8 &amp; V6]]||1982||&amp;nbsp;||Past engines: [[w:General Motors 60° V6 engine|Chevrolet 60° V6 engine]]&lt;br /&gt;[[w:GM High Value engine|GM High Value V6]]&lt;br /&gt;[[w:GM High Feature engine|GM High Feature V6]] 

|- 

|&amp;nbsp;||Ramos Arizpe Transmission||[[w:Ramos Arizpe|Ramos Arizpe]]||[[w:Mexico|Mexico]]||VT40 (CVT250) [[w:Continuously variable transmission|CVT]] transmission ||1999||&amp;nbsp;||Past transmissions: [[w:GM 4L60-E transmission|4L60-E/4L65-E 4-speed automatic]]&lt;br /&gt;[[w:GM-Ford 6-speed automatic transmission|6T70/6T75 6-speed automatic (GF6)]]&lt;br /&gt;4ET50 EVT (for [[w:Chevrolet Volt|Chevrolet Volt]])&lt;br /&gt;4ET55 EVT (for [[w:Cadillac ELR|Cadillac ELR]]) 

|-

|&amp;nbsp;||[[w:Rochester Products Division|Rochester Operations]]||[[w:Rochester, NY|Rochester, NY]]||United States||Chevrolet, GMC, Cadillac, and Buick Components - Engine management systems, fuel injection systems, and related products. ||1939||&amp;nbsp;||Located at 1000 Lexington Avenue. Founded in 1908 as the Rochester Coil Company. Renamed North East Electric Company in 1909. Acquired by GM in 1929. In 1930, merged with Delco-Light Co. to become Delco Appliance. A planned, second Delco Appliance plant on Lexington Ave. in Rochester instead became the Rochester Products Division of GM in 1939. This division made carburetors, fuel injection systems, &amp; other fuel system equipment. During WWII, it made warplane and tank electrical accessories. In 1981, Rochester Products Division merged with GM's Diesel Equipment Division of Grand Rapids, Michigan retaining the Rochester Products Division name. On August 30, 1988, Rochester Products Division merged with GM's AC Spark Plug Division to form the AC Rochester Division. The Grand Rapids-based diesel fuel-injection business of the former Diesel Equipment Division was sold on August 26 to a joint venture of G.M. and the Penske Corporation called Diesel Technology Corporation (80% Penske, 20% Detroit Diesel, itself a joint venture between Penske &amp; GM). Robert Bosch invested in Diesel Technology Corporation in 1992, eventually taking over the whole company by 2002. AC Rochester merged with parts of Delco Remy (the parts not spun off into Remy International) in 1994 to form AC Delco Systems. AC Delco Systems became part of GM's Delphi Automotive Systems subsidiary in 1995. Spun off with Delphi Automotive Systems in 1999 (Rochester Powertrain); taken back under [[w:Delphi Corporation|Delphi Corporation]] bankruptcy and made part of [[w:General Motors Components Holdings|General Motors Components Holdings]] in 2009. 

|- 

|&amp;nbsp;||[[w:Romulus Engine|Romulus Engine]]||[[w:Romulus, Michigan|Romulus, Michigan]]||United States||[[w:GM High Feature engine#Fourth generation|Gen4 High Feature V6]] 

||1976||&amp;nbsp;||Located at 36880 Ecorse Road. Originally part of GM's Detroit Diesel Allison Division where it built diesel engines and components. Switched to gasoline engines in the 1980's.&lt;br /&gt; Past engines: [[w:Chevrolet 90° V6 engine|Chevrolet 90° V6 engine]]&lt;br /&gt;[[w:General Motors LS-based small-block engine#Generation III (1997–2007)|Gen III Small Block V8]]&lt;br /&gt;[[w:GM LS engine#Generation IV (2005–2020)|Gen IV Small Block V8]] 

|- 

|&amp;nbsp;||[[w:Romulus Engine|Romulus Transmission]]||[[w:Romulus, Michigan|Romulus, Michigan]]||United States||[[w:&quot;Ford-GM 10-speed automatic transmission#General Motors|10L80/90 Transmission]]||1995||&amp;nbsp;||Located at 36880 Ecorse Road.&lt;br /&gt;Past transmissions: [[w:GM 4L60-E transmission|GM 4L60-E transmission]] 

|-

|R||Rosario||[[w:Alvear, Santa Fe|Alvear]], [[w:Rosario Department|Rosario Department]], [[w:Santa Fe Province|Santa Fe Province]]||[[w:Argentina|Argentina]]||&lt;br/&gt;[[w:Chevrolet Tracker (2019)|Chevrolet Tracker]] 

 
Engines: [[w:GM small gasoline engine#LE2|1.4L Turbo I4 LE2]] 

||1997||&amp;nbsp;||Engine plant added in 2016.  

Past Models: 

[[w:Chevrolet Cruze#Second generation (J400)|Chevrolet Cruze]], [[w:Opel Corsa#Corsa C (X01; 2000)|Chevrolet Corsa C]], [[w:Opel Corsa#Corsa B|Chevrolet Corsa B/Corsa Classic/Classic]], [[w:Chevrolet Agile|Chevrolet Agile]]&lt;br /&gt; and [[w:Chevrolet Tracker (Americas)#Second generation|Suzuki Grand Vitara/Chevrolet Tracker]] 

|- 

|&amp;nbsp;||[[w:Saginaw Metal Casting Operations|Saginaw Metal Casting Operations]]||[[w:Saginaw, Michigan|Saginaw, Michigan]]||United States||Metal casting for powertrains (High Feature V6 engine): engine blocks, heads, and crankshafts&lt;br/&gt;Front 4WD axle assembly castings||1919||&amp;nbsp;||Located at 1629 N. Washington Avenue. Originally the Grey Iron Foundry, a part of General Motors Saginaw Products Co. and renamed as Chevrolet Saginaw Grey Iron Foundry when transferred to Chevrolet Motor Division in 1927. Moved to Central Foundry Division in 1983. Joins GM Powertrain Division in 1991. Renamed Saginaw Metal Casting Operations in 1994 to reflect that it now pours aluminum. First production aluminum heads produced in 1995. Over the years, it has produced both cast iron and cast aluminum engine blocks for the Chevy Small-Block V8. 

|-

|L||[[w:San Luis Potosí Assembly|San Luis Potosí Assembly]]||[[w:San Luis Potosí, San Luis Potosí|San Luis Potosí]]||[[w:Mexico|Mexico]]||[[w:Chevrolet Equinox#Fourth generation (2025)|Chevrolet Equinox]] (2025-)&lt;br /&gt;[[w:GMC Terrain#Third generation (2025)|GMC Terrain]] (2025-)||2008||&amp;nbsp;||Note: Aveo &amp; G3 made in San Luis Potosi were not sold in the US but they were sold in Canada. Onix was not sold in the US or Canada. 2013-2014 Trax was sold in Canada &amp; Mexico but not in the US.&lt;br&gt; Past models: [[w:Chevrolet Aveo (T200)|Chevrolet Aveo (T250)]] (2009-2018)&lt;br /&gt;[[w:Pontiac G3|Pontiac G3/G3 Wave]] (2009-2010)&lt;br /&gt;[[w:Chevrolet Onix#Second generation (2019)|Chevrolet Onix]] (2020-2022)&lt;br /&gt;[[w:Chevrolet Trax#First generation (U200; 2013)|Chevrolet Trax]] (2013-2020)&lt;br /&gt;[[w:Chevrolet Equinox#Third generation (2018)|Chevrolet Equinox]] (2018-2024)&lt;ref&gt;{{Cite web|url=https://vpic.nhtsa.dot.gov/mid/home/displayfile/7c659360-416a-4e96-ae38-0b69d916c106|title=GM Vehicle Identification Numbering Standard - 2021 - United States and Canada|date=August 14, 2020}}&lt;/ref&gt;&lt;br /&gt;[[w:GMC Terrain#Second generation (2018)|GMC Terrain]] (2018-2024)

|- 

|&amp;nbsp;||San Luis Potosí Transmission||[[w:San Luis Potosí, San Luis Potosí|San Luis Potosí]]||[[w:Mexico|Mexico]]||FWD GF9 9 Speed Transmissions||2009||&amp;nbsp;||[[w:GM-Ford 6-speed automatic transmission|GM-Ford 6-speed automatic transmission]] 6T40/45 (GF6) 

|-

|B||[[w:General Motors do Brasil|São Caetano do Sul Assembly]]||[[w:São Caetano do Sul|São Caetano do Sul]], [[w:São Paulo (state)|São Paulo]]||[[w:Brazil|Brazil]]|| [[w:Chevrolet Montana#Third generation (2022)|Chevrolet Montana]] &lt;br /&gt; [[w:Chevrolet Spin|Chevrolet Spin]]&lt;br /&gt;[[w:Chevrolet Tracker (2019)|Chevrolet Tracker]]&lt;br /&gt; ||1930||&amp;nbsp;||Past Models: [[w:Opel Astra#G|Chevrolet Astra]], [[w:Opel Astra#H |Chevrolet Vectra/Vectra GT]] (both until 2011), [[w:Chevrolet C/K#1985–1996|Chevrolet Bonanza]], [[w:Chevrolet C/K#1964–1984|Chevrolet C-10/C-14/C-15/Chevy 4/D-10/A-10]], [[w:Chevrolet D-20|Chevrolet A-10/C-10/A-20/C-20/D-20]], Chevrolet A40/D40, [[w:Chevrolet Cobalt#Second generation (2011)|Chevrolet Cobalt]], [[w:Chevrolet Comodoro|Chevrolet Comodoro]], [[w:Opel Corsa#Corsa B (S93; 1993)|Chevrolet Corsa B]], [[w:Chevrolet Corsa|Chevrolet Corsa Classic]], [[w:Chevrolet Cruze#First generation (J300; 2008)|Chevrolet Cruze]], [[w:Chevrolet Diplomata|Chevrolet Diplomata]], [[w:Chevrolet Onix|Chevrolet Joy]], [[w:Chevrolet Kadett|Chevrolet Kadett]] 1996-1998, [[w:Chevrolet Montana#Second generation (2011–2021)|Chevrolet Montana]], [[w:Opel Ascona#Chevrolet Monza|Chevrolet Monza]], [[w:Chevrolet Omega#Omega A|Chevrolet Omega A]], [[w:Chevrolet Opala|Chevrolet Opala]], [[w:Opel Vectra#Vectra A (1988–1995)|Chevrolet Vectra A]], [[w:Opel Vectra#Vectra B (1995–2002)|Chevrolet Vectra B]], [[w:Chevrolet Veraneio|Chevrolet C-1416/Veraneio]], Chevrolet 3100/Brasil/Amazona/Alvorada/Corisco, Chevrolet 6500, Chevrolet C64/C65/C68/D64/D65/D68/D74/D75/D78,&lt;br&gt; Bus bodies, Frigidaire appliances 

|- 

|C||[[w:General Motors do Brasil|São José dos Campos Assembly]]||[[w:São José dos Campos|São José dos Campos]], [[w:São Paulo (state)|São Paulo]]||[[w:Brazil|Brazil]]|| 

[[w:Chevrolet S-10#Third generation (2012)|Chevrolet S-10]]&lt;br/&gt;[[w:Chevrolet Trailblazer (SUV)#Second generation (RG; 2011)|Chevrolet Trailblazer]] 

 
Engines:&lt;br/&gt; 2.8L turbodiesel &lt;br&gt; 4-cylinder engines&lt;br /&gt;

Transmissions 

|1959||&amp;nbsp;||Supplied 1.8L &amp; 2.0L SOHC Family II I4 engines to the US from 1982-1994. &lt;br /&gt;Past Models: [[w:Chevrolet Montana#First generation (2003–2010)|Chevrolet Montana]]&lt;br /&gt;  [[w:Chevrolet S-10 Blazer#Second generation (1995)|Chevrolet Blazer]], [[w:Opel Corsa#Corsa C (X01; 2000)|Chevrolet Corsa C]], [[w:Opel Corsa#Corsa C (X01; 2000)|Chevrolet Corsa Sedan C]], [[w:Opel Meriva#First generation (2003)|Chevrolet Meriva]], [[w:Opel Zafira#Zafira A (1999–2006)|Chevrolet Zafira]] (all until 2012)&lt;br /&gt;[[w:Chevrolet Chevette|Chevrolet Chevette]], [[w:Chevrolet Chevette#Chevy 500|Chevrolet Chevy 500]], [[w:Chevrolet Kadett|Chevrolet Kadett]] 1989-1996, [[w:Chevrolet S-10#Second generation (1994)|Chevrolet S-10]],  [[w:Chevrolet C/K#1997–2002|Chevrolet Silverado D20]], Chevrolet 11000/12000/14000/22000, [[w:GMC Chevette|GMC Chevette]], [[w:GMC Chevette|GMC 500]], [[w:Chevrolet C/K#1997–2002|GMC 6-100/6-150/3500HD]], [[w:Chevrolet Kodiak#Second generation (1990–2002)|GMC 12-170/14-190/16-220]], [[w:Isuzu Forward|GMC 15-190]] 

Engines including: [[w:Chevrolet Stovebolt engine#261|Chevrolet Jobmaster 261 I6]], [[w:Chevrolet 153 4-cylinder engine#Brazil|Chevrolet 153 4-cylinder]], [[w:Chevrolet Turbo-Thrift engine|Chevrolet Turbo-Thrift engine]], [[w:GM Family 1 engine|GM Family 1 engine]], [[w:GM Family II engine|GM Family II engine]]&lt;br /&gt;Detroit Diesel Series 53&lt;br /&gt;Transmissions  

|-

|G||[[Silao Assembly]]||[[w:Silao, Mexico|Silao]]||[[w:Mexico|Mexico]]||[[w:Chevrolet Silverado|Chevrolet Silverado]] (2006-)&lt;br /&gt;[[w:Chevrolet Silverado|GMC Sierra]] (2006-), Chevrolet Cheyenne (Mexico)||1995||&amp;nbsp;|| Stamping plant added in 1997. Began by building full-size SUVs for 1995. Was the sole assembler of GM's full-size SUTs. Began building full-size pickups for 2006. Full-size SUV production moved entirely to Arlington Assembly after the 2009 model year.&lt;br&gt; Past production models: [[w:Chevrolet Suburban|Chevrolet Suburban]] (1995-2009), [[w:Chevrolet Suburban#Eighth generation (1992)|GMC Suburban]] (1995-1999), [[w:GMC Yukon XL|GMC Yukon XL]] (2000-2006), [[w:Cadillac Escalade#Second generation (2002)|Cadillac Escalade ESV]] (2003-2006),&lt;br&gt; [[w:Chevrolet Suburban (eighth generation)#Holden Suburban|Holden Suburban (K8)]] (1998-2001),&lt;br&gt; [[w:Chevrolet Avalanche|Chevrolet Avalanche]] (2002-2013),&lt;br&gt; [[w:Cadillac Escalade EXT|Cadillac Escalade EXT]] (2002-2013)

|- 

|&amp;nbsp;||Silao Engine||[[w:Silao, Mexico|Silao]]||[[w:Mexico|Mexico]]||[[w:General Motors LS-based small-block engine#Generation V (2013–present)|Gen V Small Block V8]]||2001||&amp;nbsp;||[[w:General Motors LS-based small-block engine#Generation IV (2005–2020)|Gen IV Small Block V8]] 

|- 

|&amp;nbsp;||Silao Transmission||[[w:Silao, Mexico|Silao]]||[[w:Mexico|Mexico]]||[[w:GM 8L45 transmission|8L45]], [[w:GM 8L90 transmission|8L90]], [[w:Ford-GM 10-speed automatic transmission|10L80]]||2008||&amp;nbsp;||[[w:GM 6L50 transmission|6L50]], [[w:GM 6L80 transmission|6L80/90]] 

|-

|Z,&lt;br /&gt;S (Traverse &amp; Vue)||[[w:Spring Hill Manufacturing|Spring Hill Manufacturing]]||[[w:Spring Hill, Tennessee|Spring Hill, Tennessee]]||United States||&lt;br /&gt; [[w:Cadillac XT5|Cadillac XT5]] (2017-)&lt;br /&gt;[[w:Cadillac Lyriq|Cadillac Lyriq]] (2023-) &lt;br /&gt;[[w:Cadillac Vistiq|Cadillac Vistiq]] (2026-) &lt;br /&gt;&lt;br /&gt; [[w:Chevrolet Blazer|Chevrolet Blazer]] (Starting 2027) &lt;br /&gt; &lt;br /&gt;[[w:GM small gasoline engine#1.5|1.5L Turbo I4]]&lt;br /&gt;[[w:GM Ecotec engine#Generation III|Ecotec Gen III 2.0L Turbo I4]]&lt;br /&gt;[[w:GM L3B engine|2.7L L3B turbo I4]]&lt;br /&gt;5.3 &amp; 6.2 [[w:LS based GM small-block engine#Generation V (2013–present)|Gen V &lt;br /&gt;Small-Block V8 Engine]]&lt;br /&gt;&lt;br /&gt;Stamping&lt;br /&gt;Components||1990||2009-2012||Located at 100 Saturn Parkway. The original home of the [[w:Saturn Corporation|Saturn]] brand. Originally, Saturn built everything here - all its vehicles, engines, transmissions, stampings, and components. But, gradually, Saturn production was broadened to other plants and by 2007, Saturn production in Spring Hill had ended. Spring Hill made products for other GM brands and has continued to do so since Saturn was closed down during GM's bankruptcy. &lt;br /&gt; 

Past models: [[w:Saturn S-Series|Saturn S-Series]] (1991-2002), [[w:Saturn Ion|Saturn Ion]] (2003-2007), [[w:Saturn Vue#First generation (2002)|Saturn Vue]] (2002-2007), [[w:Chevrolet Traverse#First generation (2009)|Chevrolet Traverse]] (2009-2010), [[w:Chevrolet Equinox#Second generation (2010)|Chevrolet Equinox]] (2013-2016), [[w:GMC Acadia#Second generation (2017)|GMC Acadia]] (2017-2023), [[w:Holden Acadia|Holden Acadia (AC)]], [[w:Cadillac XT6|Cadillac XT6]] (2020-2025),&lt;br /&gt; [[w:Acura ZDX#Second generation (2024)|Acura ZDX EV]] (2024).&lt;br /&gt;  


Past Engines: [[w:Saturn I4 engine|Saturn I4 engine]], [[w:GM Ecotec engine#2.4|Ecotec Gen II 2.4L I4]],&lt;br&gt; [[w:GM Ecotec engine#LHU (A20NFT Opel)|Ecotec Gen II LHU 2.0L Turbo I4]], [[w:GM Ecotec engine#Generation III|Ecotec Gen III 2.5L I4]] &lt;br /&gt;  
 

[[w:Saturn MP transmission|Saturn MP series manual and automatic transmissions]] Transmission production in Spring Hill ended in 2002.  
 

Ion production ended March 28, 2007 and was replaced by the Belgian-built Astra for the 2008 model year. Vue production ended March 30, 2007 and moved to Mexico for the 2008 model year. Assembly was idled for more than a year beginning April 1, 2007 for conversion to Chevy Traverse production. Traverse production began September 2, 2008. Assembly idled in November 2009 when Chevy Traverse production was moved to Lansing Delta Township Assembly. Assembly reopened in September 2012&lt;ref&gt;{{cite news| url=https://www.nytimes.com/2011/09/18/business/general-motors-said-to-offer-bonuses-in-new-deal-with-workers.html | work=The New York Times | author1=Bill Vlasic | author2=Nick Bunkley | title=G.M. Will Offer Bonuses in New Deal With Workers | date=September 17, 2011}}&lt;/ref&gt; to produce the [[w:Chevrolet Equinox#Second generation (2010)|Chevrolet Equinox]].  

 
Spring Hill also includes a plastic injection molding operation that produce various plastic components. Plastic components have also been produced for models not built in Spring Hill such as [[w:Chevrolet Traverse|Chevrolet Traverse]] and the [[w:Chevrolet Corvette (C7)|Chevrolet Corvette (C7)]].

|- 

|&amp;nbsp;||[[w:St. Catharines Engine Plant|St. Catharines Propulsion Plant]]||[[w:St. Catharines, Ontario|St. Catharines, Ontario]]||[[w:Canada|Canada]]||[[w:General Motors LS-based small-block engine#Generation V (2013–present)|Gen V Small Block V8]]&lt;br /&gt;[[w:Tremec|Tremec]] TR-9080 8-speed dual clutch transmission&lt;br /&gt;Engine components||1954||&amp;nbsp;||Located at 570 Glendale Avenue. Operated as part of GM subsidiary McKinnon Industries, Ltd. until 1969 when it became &quot;General Motors of Canada Limited, St. Catharines&quot;.&lt;br /&gt;Previously:&lt;br /&gt;[[w:Chevrolet Turbo-Thrift engine|Chevrolet Turbo-Thrift I6 engine]] (1963-1967)&lt;br /&gt;[[w:Oldsmobile V8 engine|Oldsmobile Rocket V8 engine]] (through 1966)&lt;br /&gt;[[w:Buick V6 engine#225|Buick 225 V6 engine]] (through 1966)&lt;br /&gt;[[w:Buick V8 engine|Buick V8 engine]] (300, 340, 401) (through 1966)&lt;br /&gt; [[w:General Motors 60° V6 engine|Chevrolet 60° OHV V6 engine]] (2.8, 3.1)&lt;br /&gt;[[w:General Motors 60° V6 engine#LQ1|Chevrolet 3.4L DOHC LQ1 V6 engine]]&lt;br /&gt;[[w:GM High Feature engine|High Feature V6 engine]] (2.8, 3.6)&lt;br /&gt;[[w:Chevrolet small-block engine (first and second generation)|Chevrolet Small-Block V8]] (265/267/283/305/307/327/350)&lt;br /&gt;[[w:General Motors LS-based small-block engine#Generation III (1997–2007)|Gen III Small Block V8]]&lt;br /&gt;[[w:GM LS engine#Generation IV (2005–2020)|Gen IV Small Block V8]]&lt;br /&gt;[[w:GM 6T40 transmission|(GF6) 6T45 6-speed automatic]] 

|- 

|&amp;nbsp;||[[w:Toledo Transmission|Toledo Transmission]]||[[w:Toledo, Ohio|Toledo, Ohio]]||United States||Transmissions:&lt;br /&gt; RWD GM-Allison 10-speed (10L1000) (AB1V) / 8-speed ([[w:GM 8L45 transmission|8L45]] &amp; [[w:GM 8L90 transmission|8L90]]) &lt;br /&gt; FWD GF9 9 Speed Transmissions||1956|| ||Located at 1455 West Alexis Road. Acquired from the former Martin-Parry Corporation in 1955. Replaced the older Toledo plant on Central Ave. &lt;br /&gt;Previously:&lt;br /&gt; [[w:Turbo-Hydramatic#THM350|THM350 3-speed automatic]]&lt;br /&gt;[[w:Turbo-Hydramatic#THM700R4 / 4L60 / 4L60E / 4L65E / 4L70E|THM700R4/4L60 4-speed automatic]]&lt;br /&gt;[[w:GM 4L60-E transmission|4L60-E/4L65-E/4L70-E 4-speed automatic]]&lt;br /&gt;[[w:GM 6T40 transmission|(GF6) 6T30/35/40/45/50 6-speed automatic]] &lt;br /&gt; ([[w:GM 6L50 transmission|6L45/6L50]] &amp; [[w:GM 6L80 transmission|6L80/6L90]]) 6-speed automatics

|-

||&amp;nbsp;||Toluca Engine||[[w:Toluca|Toluca]], [[w:State of Mexico|State of Mexico]] 

|[[w:Mexico|Mexico]] 

|[[w:GM small gasoline engine|GM Small Gasoline Engine 1.4L/1.5L I4]] (including 1.5 turbo LSD I4 for Equinox/Terrain)

[[w:Chevrolet 153 4-cylinder engine#Vortec 3000|Vortec 3000 Marine &amp; Industrial 4-cyl. engine]]&lt;br /&gt;  

5.0 &amp; 5.7 Marine &amp; Industrial V8 engines&lt;br /&gt; 

Small-Block V8 engines for the aftermarket&lt;br /&gt;  

Aluminum Foundry&lt;br /&gt;  

|1965 

| 

|Past engines: 
[[w:GM Family 1 engine|GM Family 1 I4 engine]] &lt;br /&gt;[[w:Chevrolet Turbo-Thrift engine#292|Chevrolet 292 (4.8L) Inline-6]]

|-

|&amp;nbsp;||[[w:Tonawanda Engine|Tonawanda Engine]]||[[w:Buffalo, New York|Buffalo, New York]]||United States||[[w:LS based GM small-block engine#LV1|LV1]] 4.3L V6 

 
[[w:LS based GM small-block engine#L84|L84]] 5.3L V8 

 
[[w:LS based GM small-block engine#L86/L87|L87]] 6.2L V8 

 
[[w:General Motors LS-based small-block engine#LT2|LT2]] 6.2L V8 

 
[[w:LS based GM small-block engine#L8T|L8T]] 6.6L V8 

 
[[w:GM Ecotec engine#LSY|LSY]] 2.0T I4 

 
|1938 

|&amp;nbsp;||Located at 2995 River Rd. Includes 3 plants. Plant #1 opened in 1938. Plant #4 opened in 1941. Plant #5 opened in 2001.  

Past engines:  

Built the [[w:Pratt &amp; Whitney R-1830 Twin Wasp|Pratt &amp; Whitney R-1830 Twin Wasp]] radial engine used in the [[w:B-24 Liberator|B-24 Liberator]] bomber during WW-2 

Built the [[w:Pratt &amp; Whitney R-2800 Double Wasp|Pratt &amp; Whitney R-2800 Double Wasp]] radial engine used in the [[w:P-61 Black Widow|P-61 Black Widow]] &amp; [[w:P-47 Thunderbolt|P-47 Thunderbolt]] fighters during WW-2 


[[w:Chevrolet 2300 engine|Chevrolet 2300 engine]] (Vega I4)


[[w:General Motors 122 engine|Chevrolet 122 engine]] (1.8/2.0/2.2L OHV I4)

 
[[w:GM Ecotec engine#2.2|Ecotec 2.2L Gen I]] (L850) 

 
[[w:GM Ecotec engine#2.2_2|Ecotec 2.2L Gen II]], [[w:GM Ecotec engine#2.4|Ecotec 2.4L Gen II]] 

 
[[w:GM Ecotec engine#LTG|Ecotec Gen III LTG 2.0T I-4]], [[w:GM Ecotec engine#2.5|Ecotec 2.5L Gen III]] 


[[w:General Motors Atlas engine#LK5 (Vortec 2800)|Atlas 2.8/2.9 I4]]&lt;br /&gt;[[w:General Motors Atlas engine#L52 (Vortec 3500)|Atlas 3.5/3.7 I5]] 
 

[[w:Chevrolet Turbo-Air 6 engine|Corvair Flat-6 (all)]] 


[[w:Chevrolet Stovebolt engine#Second generation: 1937–1962|Chevrolet Stovebolt / Blue Flame I6]] 


[[w:Chevrolet 90° V6 engine|Chevrolet 3.3L/3.8L/4.3L 90° V6]] 

 
[[w:General Motors 60° V6 engine|Chevrolet 60° V6 engine]], [[w:GM High Value engine|High Value 3.9L V6]] 

 
[[w:Chevrolet small-block engine (first and second generation)|Chevrolet Small-Block V8]] 


[[w:Chevrolet Big-Block engine|Chevrolet Big-Block V8]] 

 
Gen V Small-Block 90° V6/V8: [[w:LS based GM small-block engine#LV3|LV3]] 4.3L V6, [[w:LS based GM small-block engine#L82|L82]] 5.3L V8, [[w:LS based GM small-block engine#L83|L83]] 5.3L V8, [[w:LS based GM small-block engine#L86|L86]] 6.2L V8, [[w:LS based GM small-block engine#LT1|LT1]] 6.2L V8, [[w:LS based GM small-block engine#LT4|LT4 6.2L Supercharged V8]] 

|- 

|&amp;nbsp;||[[w:Ultium#Production|Ultium Cells LLC - Spring Hill]]||[[w:Spring Hill, Tennessee|Spring Hill, Tennessee]]||United States||Ultium lithium-ion battery cells for EV's||2024|| || Owned by Ultium Cells LLC, a 50/50 joint venture between General Motors and [[w:LG Energy Solution|LG Energy Solution]]. This is Ultium Cells' second plant. Located at 301 Donald F Ephlin Pkwy.
  
|- 

|&amp;nbsp;||[[w:Ultium#Production|Ultium Cells LLC - Warren]]||[[w:Warren, Ohio|Warren, Ohio]]||United States||Ultium lithium-ion battery cells for EV's||2022|| || Owned by Ultium Cells LLC, a 50/50 joint venture between General Motors and [[w:LG Energy Solution|LG Energy Solution]]. This is Ultium Cells' first plant. Located at 7400 Tod Ave SW.
 
|- 

|1||[[w:Wentzville Assembly|Wentzville Assembly]]||[[w:Wentzville, Missouri|Wentzville, Missouri]]||United States||[[w:Chevrolet Express|Chevrolet Express]] (1996-)&lt;br /&gt;[[w:GMC Savana|GMC Savana]] (1996-)&lt;br /&gt;[[w:Chevrolet Colorado|Chevrolet Colorado]] (2015-)&lt;br /&gt;[[w:GMC Canyon|GMC Canyon]] (2015-)||1983||&amp;nbsp;||Located at 1500 E. Rte. A. Originally opened to build the 1985 Fwd C-bodies. Began building Fwd H-bodies for 1986. On Oct. 29, 1991, Wentzville built the 30 millionth Pontiac, a white 1992 Bonneville SSEi. Ended passenger car production in 1994. Converted to truck production. Began building full-size vans in 1996. Added midsize pickups in 2014.  &lt;br /&gt;Past models: [[w:Buick Electra#Sixth generation (1985–1990)|Buick Electra]] (1985-1990), [[w:Buick Park Avenue#First generation (1991–1996)|Buick Park Avenue]] (1991-1994), [[w:Oldsmobile 88#Ninth generation (1986–1991)|Oldsmobile Delta 88/88]] (1986-1991),&lt;br&gt; [[w:Oldsmobile 88#Tenth generation (1992–1999)|Oldsmobile 88]] (1992-1993), [[w:Oldsmobile 98#Eleventh generation (1985–1990)|Oldsmobile 98]] (1985-1989), [[w:Oldsmobile Touring Sedan|Oldsmobile Touring Sedan]] (1989),&lt;br&gt; [[w:Pontiac Bonneville#Eighth generation (1987–1991)|Pontiac Bonneville]] (1989-1991), [[w:Pontiac Bonneville#Ninth generation (1992–1999)|Pontiac Bonneville]] (1992-93)

|-

|A||[[w:SAIC-GM|SAIC-GM]] Shanghai plant||[[w:Jinqiao|Jinqiao]], [[w:Pudong|Pudong]] district, [[w:Shanghai|Shanghai]]||[[w:China|China]]||[[w:Cadillac CT4|Cadillac CT4]]&lt;br /&gt;[[w:Cadillac CT5|Cadillac CT5]]&lt;br /&gt;[[w:Cadillac CT6|Cadillac CT6]]&lt;br /&gt;[[w:Cadillac Lyriq|Cadillac Lyriq]]&lt;br /&gt;[[w:Cadillac Vistiq|Cadillac Vistiq]]&lt;br&gt;[[w:Cadillac XT4|Cadillac XT4]]&lt;br /&gt;[[w:Cadillac XT5|Cadillac XT5]]&lt;br /&gt;[[w:Cadillac XT6|Cadillac XT6]]&lt;br /&gt;[[w:Chevrolet Blazer (crossover)#Chinese version|Chevrolet Blazer]]&lt;br /&gt;[[w:Chevrolet Malibu#Ninth generation (2016)|Chevrolet Malibu XL]]&lt;br /&gt;[[w:Buick Enclave#China (2020)|Buick Enclave]]&lt;br /&gt;[[w:Buick GL8#Third generation (2017–present)|Buick GL8 ES/Avenir/PHEV (Mk III)]]&lt;br /&gt;[[w:Buick GL8#Fourth generation (2022)|Buick GL8 Century (Mk IV)]]&lt;br /&gt;[[w:Buick GL8#Electra Encasa (2025)|Buick Electra Encasa (Mk V)]]&lt;br /&gt;[[w:Buick LaCrosse|Buick LaCrosse]]&lt;br /&gt;[[w:Buick Regal#Sixth generation (2018)|Buick Regal]] (E2XX)&lt;br /&gt;Engines&lt;br /&gt;Engine components&lt;br /&gt;Transmissions&lt;br /&gt;Ultium batteries||1998||&amp;nbsp;||Operated by [[w:SAIC-GM|SAIC-GM]]. There are 3 vehicle production plants (North, South, &amp; East). North was the original plant. South began production in 2005. The East or &quot;Cadillac&quot; plant began production in 2016. On October 28, 2025, the Shanghai plant produced its 4 millionth vehicle, a 2026 Cadillac XT5.  

Past models: [[w:Buick Century#Sixth generation (1997–2005)|Buick New Century]] (W-body)&lt;br /&gt;[[w:Buick Excelle#First generation (J200; 2003)|Buick Excelle]]&lt;br /&gt;[[w:Buick GL8#First generation (2000–2016)|Buick GL8 Mk I (1999-2004)]]&lt;br /&gt;[[w:Buick Park Avenue#Third generation (2007–2012)|Buick Park Avenue (WM)]] (CKD)&lt;br /&gt;[[w:Buick Regal#China|Buick Regal]] (W-body)&lt;br /&gt;[[w:Buick Regal#Fifth generation (2008)|Buick Regal]] (Epsilon II)&lt;br /&gt;[[w:Buick Sail|Buick Sail]]&lt;br /&gt;[[w:Buick Velite 5|Buick Velite 5]]&lt;br /&gt;[[w:Buick Velite 7|Buick Velite 7]]&lt;br /&gt;[[w:Chevrolet Malibu#Eighth generation (2013)|Chevrolet Malibu]]&lt;br /&gt;[[w:Cadillac ATS#ATS-L|Cadillac ATS-L]]&lt;br /&gt;[[w:Cadillac CTS#First generation (2003)|Cadillac CTS]]&lt;br /&gt;[[w:Cadillac STS#Chinese Cadillac SLS|Cadillac SLS]]&lt;br /&gt;[[w:Cadillac XTS|Cadillac XTS]]&lt;br /&gt; 

Past Engines: [[w:General Motors 60° V6 engine#Production in China by SAIC-GM|Chevrolet 60° OHV V6]] 

|-

|D||[[w:SAIC-GM|SAIC-GM]] Dongyue Motors||[[w:Yantai|Yantai]], [[w:Shandong|Shandong]]||[[w:China|China]]||[[w:Buick Envision|Buick Envision]]&lt;br /&gt;[[w:Cadillac GT4|Cadillac GT4]]||2001||&amp;nbsp;||Operated by [[w:SAIC-GM|SAIC-GM]]. Originally founded in 2001 as Yantai Bodyshop Corp. which built Daewoo vehicles ([[w:Daewoo Lanos|Daewoo Lanos]]) under license from Daewoo Motor Co. SAIC-GM took over the plant in 2002. There are 2 vehicle production plants (North &amp; South). SAIC-GM Dongyue Motors joint venture is owned 50% by SAIC-GM, 25% by GM China, &amp; 25% by SAIC. &lt;br /&gt; 

Past models: [[w:Buick Encore#First generation (2013)|Buick Encore]]&lt;br /&gt;[[w:Buick Encore GX|Buick Encore GX]]&lt;br /&gt;[[w:Buick Encore GX|Buick Encore Plus]]&lt;br /&gt;[[w:Buick Excelle#Second generation (2018)|Buick Excelle]]&lt;br /&gt;[[w:Buick Excelle GT#First generation (2009)|Buick Excelle GT/XT]]&lt;br /&gt;[[w:Chevrolet Sail#Buick Sail|Buick Sail]]&lt;br /&gt;[[w:Chevrolet Aveo#Second generation (T300; 2012)|Chevrolet Aveo (T300)]]&lt;br /&gt;[[w:Chevrolet Sail#Third generation (2014)|Chevrolet Aveo (Mex.)]]&lt;br /&gt;[[w:Chevrolet Sail#Chevrolet Sail|Chevrolet Corsa Plus (Chile)]]&lt;br /&gt;[[w:Daewoo Magnus|Chevrolet Epica (V200)]]&lt;br /&gt;[[w:Daewoo Tosca|Chevrolet Epica]] (V250)&lt;br /&gt;[[w:Chevrolet Aveo (T200)|Chevrolet Lova]]&lt;br /&gt;[[w:Chevrolet Lova RV|Chevrolet Lova RV]]&lt;br /&gt;[[w:Chevrolet Onix#Second generation (2019)|Chevrolet Onix]]&lt;br /&gt;[[w:Chevrolet Orlando#Second generation (2018)|Chevrolet Orlando]]&lt;br /&gt;[[w:Chevrolet Sail|Chevrolet Sail]]&lt;br /&gt;[[w:Chevrolet Trailblazer (crossover)|Chevrolet Trailblazer]]&lt;br /&gt;[[w:Chevrolet Trax|Chevrolet Trax]] 

|- 

|&amp;nbsp;||[[w:SAIC-GM|SAIC-GM]] Dongyue Powertrain||[[w:Yantai|Yantai]], [[w:Shandong|Shandong]]||[[w:China|China]]||Engines&lt;br /&gt;Transmissions including: [[w:GM 6T40 transmission|6T30/6T40/6T45/6T50]], [[w:Continuously variable transmission|CVT]]||1999||&amp;nbsp;||Operated by [[w:SAIC-GM|SAIC-GM]]. Originally founded in 1999 as Shandong Daewoo Automotive Engine Co., Ltd., a 50/50 joint venture between Daewoo Motor Co. &amp; Chinese partners owned by the Shandong provincial govt. SAIC-GM took over the plant in 2005. SAIC-GM Dongyue Powertrain joint venture is owned 50% by SAIC-GM, 25% by GM China, &amp; 25% by SAIC. &lt;br /&gt; 

Past Engines: [[w:GM Family 1 engine#Generation III|Family I, Gen 3 engine]]   

|- 

|&amp;nbsp;||[[w:SAIC-GM|SAIC-GM]] Norsom Motors||[[w:Shenyang|Shenyang]], [[w:Liaoning|Liaoning]]||[[w:China|China]]|| ||1992||2025||Operated by [[w:SAIC-GM|SAIC-GM]]. Originally founded in 1992 as Jinbei GM Automotive Co. Ltd., a 30/70 joint venture between GM &amp; Shenyang Jinbei Automotive. Restructured into a 50/50 joint venture between GM &amp; Jinbei in 1998. SAIC-GM took over the joint venture in 2004, buying out Jinbei. The new SAIC-GM Norsom Motors joint venture is owned 50% by SAIC-GM, 25% by GM China, &amp; 25% by SAIC. Plant closed in February 2025 due to declining sales in China by SAIC-GM.

Past models:&lt;br /&gt; Jinbei GM:&lt;br /&gt;[[w:Chevrolet S-10 Blazer#Second generation (1995–2005)|Chevrolet Blazer]]&lt;br /&gt;[[w:Chevrolet S-10#Second generation (1994)|Chevrolet S-10 Crew Cab]]&lt;br /&gt;SAIC-GM:&lt;br /&gt;[[w:Chevrolet Cruze|Chevrolet Cruze]]&lt;br /&gt;[[w:Chevrolet Captiva#First generation (C100, C140; 2006)|Chevrolet Captiva]]&lt;br /&gt;[[w:Chevrolet Tracker (2019)|Chevrolet Tracker]] &lt;br /&gt;[[w:Chevrolet Seeker|Chevrolet Seeker]]&lt;br/&gt; [[w:Buick Encore#Second generation (2020)|Buick Encore]]&lt;br /&gt;[[w:Buick Envista|Buick Envista]]&lt;br /&gt;[[w:Buick GL8#First generation (2000–2016)|Buick GL8 Mk I (2004-2016)]]&lt;br /&gt;[[w:Buick GL8#Second generation (2010-present)|Buick GL8 Land Business Class (Mk II) (2010-2025)]]&lt;br /&gt;[[w:Buick Verano#Second generation (2016)|Buick Verano]] &lt;br/&gt; Engines

|- 

|V||[[w:SAIC-GM|SAIC-GM]] Wuhan Branch||[[w:Wuhan|Wuhan]], [[w:Hubei|Hubei]]||[[w:China|China]]||[[w:Chevrolet Equinox#Fourth generation (2025)|Chevrolet Equinox Plus]]&lt;br /&gt;[[w:Chevrolet Monza (China)|Chevrolet Monza]]&lt;br /&gt;[[w:Chevrolet Menlo|Chevrolet Menlo]]&lt;br /&gt;[[w:Buick Verano#Third generation (Pro, 2021)|Buick Verano Pro]]&lt;br /&gt;[[w:Buick Velite 6|Buick Velite 6]]&lt;br /&gt;[[w:Buick Electra E5|Buick Electra E5]]&lt;br /&gt;[[w:Buick Electra L7|Buick Electra L7]]&lt;br /&gt;[[w:Buick Electra E7|Buick Electra E7]]&lt;br /&gt;[[w:Cadillac Optiq|Cadillac Optiq]]&lt;br /&gt; Engines||2015&lt;ref&gt;{{Cite news |author=Joseph Szczesny |date=30 January 2015 |title=Ford, GM Implement Expansion Plans in China |work=The Detroit Bureau |url=https://www.thedetroitbureau.com/2015/01/ford-gm-implement-expansion-plans-in-china/ |access-date=19 June 2022}}&lt;/ref&gt;||&amp;nbsp;||Operated by [[w:SAIC-GM|SAIC-GM]].&lt;ref&gt;{{Cite news |author=Jamie L. LaReau |date=27 February 2020 |title=Restart of GM's plant in China stalls due to coronavirus crisis |work=Detroit Free Press |url=https://www.freep.com/story/money/cars/general-motors/2020/02/27/gm-delays-start-production-china-plant-due-coronavirus-crisis/4884203002/ |access-date=19 June 2022}}&lt;/ref&gt; 

Past models: [[w:Chevrolet Cavalier#China|Chevrolet Cavalier]] &lt;br /&gt;[[w:Chevrolet Equinox#Third generation (2018)|Chevrolet Equinox]]&lt;br /&gt;[[w:Buick Electra E4|Buick Electra E4]]&lt;br /&gt;[[w:Buick Excelle GT#Second generation (2015)|Buick Excelle GT/GX]]&lt;ref&gt;{{Cite news |author=Sam McEachern|date=28 February 2020 |title=GM Delays Production Restart At Wuhan Plant As Coronavirus Crisis Continues |work=GM Authority |url=https://gmauthority.com/blog/2020/02/gm-delays-production-restart-at-wuhan-plant-as-coronavirus-crisis-continues/ |access-date=19 June 2022}}&lt;/ref&gt;&lt;br /&gt;[[w:Buick GL6|Buick GL6]]

|-

|&amp;nbsp;||[[w:SAIC-GM-Wuling|SAIC-GM-Wuling]] (HQ plant)||[[w:Liuzhou|Liuzhou]], [[w:Guangxi Zhuang Autonomous Region|Guangxi Zhuang Autonomous Region]]||[[w:China|China]]|| [[w:SAIC-GM-Wuling|Wuling]] models&lt;br /&gt;Engines||1982||&amp;nbsp;||Operated by [[w:SAIC-GM-Wuling|SAIC-GM-Wuling]]. There are 2 vehicle production plants (East &amp; West). SAIC &amp; GM jointly created the joint venture with Wuling in 2002. The SAIC-GM-Wuling joint venture was originally owned 50.1% by SAIC, 34% by GM China, &amp; 15.9% by Liuzhou Wuling Automobile Industry Co., Ltd. Since 2011, SAIC-GM-Wuling is now owned 50.1% by SAIC, 44% by GM China, &amp; 5.9% by Liuzhou Wuling Motors Co., Ltd. Engine plant added in 2007.  

Past models: [[w:Chevrolet Spark#Lechi (China)|Chevrolet Lechi (Spark)]], [[w:Baojun 630|Baojun 630]] 

|- 

|&amp;nbsp;||[[w:SAIC-GM-Wuling|SAIC-GM-Wuling]] [[w:Baojun|Baojun]] Base||Liudong New District, [[w:Liuzhou|Liuzhou]], [[w:Guangxi Zhuang Autonomous Region|Guangxi Zhuang Autonomous Region]]||[[w:China|China]]|| [[w:Baojun|Baojun]] models&lt;br /&gt;Engines||2012||&amp;nbsp;||Operated by [[w:SAIC-GM-Wuling|SAIC-GM-Wuling]]. SAIC &amp; GM jointly created the joint venture with Wuling in 2002. The SAIC-GM-Wuling joint venture was originally owned 50.1% by SAIC, 34% by GM China, &amp; 15.9% by Liuzhou Wuling Automobile Industry Co., Ltd. Since 2011, SAIC-GM-Wuling is now owned 50.1% by SAIC, 44% by GM China, &amp; 5.9% by Liuzhou Wuling Motors Co., Ltd. Engine plant added in 2015.  

Past models: [[w:Chevrolet Spark#Lechi (China)|Baojun Lechi]], [[w:Baojun 610|Baojun 610]], [[w:Baojun 630|Baojun 630]]  

|- 

|&amp;nbsp;||[[w:SAIC-GM-Wuling|SAIC-GM-Wuling]] Chongqing Branch||[[w:Chongqing|Chongqing]]||[[w:China|China]]|| [[w:SAIC-GM-Wuling|Wuling]] models&lt;br /&gt;Engines||2014||&amp;nbsp;||Operated by [[w:SAIC-GM-Wuling|SAIC-GM-Wuling]]. Since 2011, SAIC-GM-Wuling is owned 50.1% by SAIC, 44% by GM China, &amp; 5.9% by Liuzhou Wuling Motors Co., Ltd.   

|- 

|&amp;nbsp;||[[w:SAIC-GM-Wuling|SAIC-GM-Wuling]] Qingdao Branch||[[w:Qingdao|Qingdao]], [[w:Shandong|Shandong]]||[[w:China|China]]|| [[w:SAIC-GM-Wuling|Wuling]] models&lt;br /&gt;Engines||2000||&amp;nbsp;||Operated by [[w:SAIC-GM-Wuling|SAIC-GM-Wuling]]. Originally founded in 1997 as [[w:Etsong Vehicle Manufacturing|Etsong Vehicle Manufacturing]]. SAIC-GM-Wuling took over the plant in 2005. Since 2011, SAIC-GM-Wuling is owned 50.1% by SAIC, 44% by GM China, &amp; 5.9% by Liuzhou Wuling Motors Co., Ltd. Engine plant added in 2009.  

|-

|J||[[w:SGMW Motor Indonesia|SGMW Motor Indonesia]]||[[w:Cikarang|Cikarang]], [[w:West Java|West Java]]||[[w:Indonesia|Indonesia]]|| [[w:Wuling Air EV|Wuling Air EV]]&lt;br /&gt;[[w:Wuling Binguo|Wuling Binguo EV]]&lt;br /&gt;[[w:Wuling Cloud EV|Wuling Cloud EV ]]&lt;br /&gt;[[w:Wuling Almaz|Wuling Almaz]]&lt;br /&gt;[[w:Wuling Alvez|Wuling Alvez]]&lt;br /&gt;[[w:Wuling Confero|Wuling Confero]]&lt;br /&gt;[[w:Wuling Cortez|Wuling Cortez]]&lt;br /&gt;[[w:Wuling Formo|Wuling Formo]]&lt;br /&gt;[[w:MG4 EV|MG4 EV]], [[w:MG ZS (crossover)|MG ZS EV]]||2017||&amp;nbsp;||100% owned and operated by [[w:SAIC-GM-Wuling|SAIC-GM-Wuling]]. Since 2011, SAIC-GM-Wuling is owned 50.1% by SAIC, 44% by GM China, &amp; 5.9% by Liuzhou Wuling Motors Co., Ltd. In 2024, SGMW Motor Indonesia began producing MG models on behalf of PT SAIC Motor Indonesia. MG is owned by SAIC, a shareholder of SGMW. 

Past models: [[w:Chevrolet Captiva#Second generation (CN202S; 2019)|Chevrolet Captiva]] 

|}

== Current partner factories == 

 
{| class=&quot;wikitable sortable&quot; style=&quot;font-size:90%&quot; 

!VIN !! Name !! City/State !! Country !! class=&quot;unsortable&quot; | Products !! Opened !! Idled !! class=&quot;unsortable&quot; | Comments 

|- 

|&amp;nbsp;||[[Azermash CP LLC]]||[[w:Hajiqabul|Hajiqabul]]||[[w:Azerbaijan|Azerbaijan]]||[[w:Chevrolet Cobalt#Second generation (2011)|Chevrolet Cobalt]], [[w:Chevrolet Lacetti|Chevrolet Lacetti]], [[w:Chevrolet Malibu#Ninth generation (2016)|Chevrolet Malibu]], [[w:Chevrolet Onix#Second generation (2019)|Chevrolet Onix]], [[w:Chevrolet Aveo (T200)|Chevrolet Nexia (T250)]], [[w:Chevrolet Tracker (2019)|Chevrolet Tracker]], [[w:Suzuki Carry#Daewoo Damas|Chevrolet Damas/Labo]] ||2017|| ||Built under contract by Azermash CP LLC for GM &amp; UzAuto Motors.  

|- 

|A||[[w:GM Uzbekistan|GM Uzbekistan]]/[[w:UzAuto Motors|UzAuto Motors]]||[[w:Asaka, Uzbekistan|Asaka]], [[w:Andijan Region|Andijan Region]]||[[w:Uzbekistan|Uzbekistan]]||[[w:Chevrolet Cobalt#Second generation (2011)|Chevrolet Cobalt]], [[w:Chevrolet Lacetti|Chevrolet Lacetti]], [[w:Chevrolet Onix#Second generation (2019)|Chevrolet Onix]],  [[w:Chevrolet Tracker (2019)|Chevrolet Tracker (2022-)]]||1996|| ||Originally established as Uz-DaewooAuto, a 50/50 joint venture between Daewoo Motor &amp; the Uzbek government. Became GM Uzbekistan, a 25/75 joint venture between GM &amp; state owned UzAvtosanoat in 2008. GM was bought out by the Uzbek govt. in 2019 &amp; the company was renamed UzAuto Motors. Vehicles now built under license from GM by UzAuto Motors.  

Previous models: [[w:Daewoo Tico|Daewoo Tico]], [[w:Chevrolet Spark#First generation (M100, M150; 1998)|Daewoo Matiz (M150)]], [[w:Daewoo Nexia|Daewoo Nexia]], [[w:Daewoo Nexia|Chevrolet Nexia]], [[w:Daewoo Gentra#Uzbekistan (2013–2015)|Daewoo Gentra]], [[w:Daewoo Damas|Daewoo Damas]], [[w:Daewoo Labo|Daewoo Labo]], [[w:Chevrolet Captiva#First generation (C100, C140; 2006)|Chevrolet Captiva]], [[w:Chevrolet Epica|Chevrolet Epica]], [[w:Chevrolet Aveo (T200)|Chevrolet Nexia 3]], [[w:Chevrolet Spark#Third generation (M300; 2009)|Chevrolet Spark (M300)]], [[w:Chevrolet Tacuma|Chevrolet Tacuma]], [[w:Chevrolet Trax|Chevrolet Tracker]], [[w:Chevrolet Spark#First generation (M100, M150; 1998)|Ravon Matiz]], [[w:Chevrolet Spark#Third generation (M300; 2009)|Ravon R2]], [[w:Chevrolet Aveo#Ravon Nexia R3|Ravon Nexia R3]], [[w:Chevrolet Cobalt#Second generation (2011)|Ravon R4]], [[w:Daewoo Gentra|Ravon Gentra R5]] 

|- 

|&amp;nbsp;||[[w:GM Uzbekistan|GM Uzbekistan]]/[[w:UzAuto Motors|UzAuto Motors]]||[[w:Pitnak|Pitnak]], [[w:Khorezm Region|Khorezm Region]]||[[w:Uzbekistan|Uzbekistan]]||[[w:Chevrolet Damas|Chevrolet Damas]]&lt;br&gt; [[w:Chevrolet Labo|Chevrolet Labo]]  ||2014|| ||Was part of GM Uzbekistan, a 25/75 joint venture between GM &amp; state owned UzAvtosanoat formed in 2008. GM was bought out by the Uzbek govt. in 2019 &amp; the company was renamed UzAuto Motors. Vehicles now built under license from GM by UzAuto Motors. In 2021, a new press shop opened at the Pitnak plant. 

Previous models: [[w:Chevrolet Orlando#First generation (J309; 2010)|Chevrolet Orlando]], [[w:Daewoo Damas|Daewoo Damas]], [[w:Daewoo Labo|Daewoo Labo]]   

|- 

|&amp;nbsp;||[[w:GM Uzbekistan|GM Uzbekistan]]/[[w:UzAuto Motors|UzAuto Motors]]||[[w:Tashkent|Tashkent]]||[[w:Uzbekistan|Uzbekistan]]||Repair of used cars ||2009||2019||Was part of GM Uzbekistan, a 25/75 joint venture between GM &amp; state owned UzAvtosanoat formed in 2008. GM was bought out by the Uzbek govt. in 2019 &amp; the company was renamed UzAuto Motors. Vehicles now built under license from GM by UzAuto Motors. Plant assembled SKD vehicles. SKD production ended in 2019. Plant is now used to repair &amp; overhaul used cars acquired as trade-ins for new cars, which are then resold by UzAuto.   

Previous models: [[w:Chevrolet Captiva#First generation (C100, C140; 2006)|Chevrolet Captiva]], [[w:Chevrolet Malibu#Eighth generation (2013)|Chevrolet Malibu]], [[w:Chevrolet Malibu#Ninth generation (2016)|Chevrolet Malibu]], [[w:Chevrolet Trax|Chevrolet Tracker (initial production from SKD)]] 

|- 

|&amp;nbsp;||[[w:GM Uzbekistan|GM Powertrain Uzbekistan]]/[[w:GM Uzbekistan|UzAuto Motors Powertrain]]||[[w:Tashkent|Tashkent]]||[[w:Uzbekistan|Uzbekistan]]||[[w:Daewoo S-TEC engine|1.2L &amp; 1.5L DOHC I4 engines]]&lt;br /&gt;[[w:GM E-Turbo engine|1.2L GM E-Turbo I3 engine]]&lt;br /&gt;Engine components (crankshaft, block, heads)&lt;br /&gt;Aluminum Foundry ||2011|| ||GM Powertrain Uzbekistan is a 52/48 joint venture between GM &amp; state owned UzAvtosanoat. In 2019, the company was renamed UzAuto Motors Powertrain after UzAvtosanoat bought out GM's share of the joint venture. It now builds engines &amp; components under license from GM.

|- 

|0,4,7,8,9||[[w:Isuzu|Isuzu]] Fujisawa plant||[[w:Fujisawa, Kanagawa|Fujisawa, Kanagawa]]||[[w:Japan|Japan]]||[[w:Isuzu Elf|Chevrolet Low Cab Forward 4500 &amp; 5500 diesel]] (2016-)&lt;br /&gt;[[w:Isuzu N-Series|Isuzu N-Series]]&lt;br /&gt;[[w:Isuzu F-Series|Isuzu F-Series]]||1961||&amp;nbsp;||[[w:Isuzu|Isuzu]] plant. &lt;br /&gt; Previous models:&lt;br /&gt; [[w:Isuzu Gemini#In other markets|Buick Opel]] (1976-1979)&lt;br /&gt;[[w:Chevrolet LUV|Chevrolet LUV]] (1972-1982)&lt;br /&gt;[[w:Chevrolet Spectrum|Chevrolet Spectrum]] (1985-1988)&lt;br /&gt;[[w:Chevrolet W-Series|Chevrolet W-Series]] (1986-2009)&lt;br /&gt;[[w:Geo Spectrum|Geo Spectrum]] (1989)&lt;br /&gt;[[w:Geo Storm|Geo Storm]] (1990-1993)&lt;br /&gt;[[w:GMC W-Series|GMC W-Series]] (1986-2009)&lt;br /&gt;[[w:Isuzu Faster#First generation (1972–1980)|Bedford KB25]]&lt;br /&gt;[[w:Isuzu Faster#Second generation (1980–1988)|Bedford KB26/41]]&lt;br /&gt;[[w:Opel Campo#Third generation (TF; 1988–2002)|Opel Campo/Bedford Brava/Vauxhall Brava]]&lt;br /&gt;[[w:Holden Jackaroo#First generation (1981)|Holden Jackaroo (Gen 1)]]&lt;br /&gt;[[w:Opel Monterey#Second generation (1991)|Opel/Vauxhall Monterey/Holden Jackaroo (Gen 2)/Monterey]]&lt;br /&gt;[[w:Holden Rodeo|Holden Rodeo]] (1981-2002) (KB/TF)&lt;br /&gt;[[w:Holden Piazza#First generation (JR120/130; 1980)|Holden Piazza]]&lt;br /&gt;[[w:Holden Shuttle|Holden Shuttle]]&lt;br /&gt;[[w:Isuzu I-Mark|Isuzu I-Mark]], [[w:Isuzu Impulse|Isuzu Impulse]], [[w:Isuzu Stylus|Isuzu Stylus]]

|- 

|H||[[w:Navistar|Navistar]] - Springfield Assembly Plant (Main Line)||[[w:Springfield, Ohio|Springfield, Ohio]]||[[w:United States|United States]]||[[w:Chevrolet Silverado#Medium duty version (4500HD, 5500HD, 6500HD, and International CV)|Chevrolet Silverado Medium Duty (2019-)&lt;br /&gt;International CV]] (2019-)||2019|| ||Located at 6125 Urbana Road. Jointly developed by GM &amp; Navistar. Built under contract by [[w:Navistar|Navistar]] for GM.  

|- 

|N||[[w:Navistar|Navistar]] - Springfield Assembly Plant (Secondary Line)||[[w:Springfield, Ohio|Springfield, Ohio]]||[[w:United States|United States]]||[[w:Chevrolet Express|Chevrolet Express]] cutaway (2017-),&lt;br /&gt; [[w:GMC Savana|GMC Savana]] cutaway (2017-)||2017|| ||Located at 6125 Urbana Road. Built under contract by [[w:Navistar|Navistar]] for GM.  

|- 

|&amp;nbsp;||PACE (Planta Automotiva do Ceará=Ceará Automotive Plant)||[[w:Horizonte, Ceará|Horizonte, Ceará]]||[[w:Brazil|Brazil]]||[[w:Chevrolet Spark EUV|Chevrolet Spark EUV]] (2026-),&lt;br /&gt; [[w:Wuling Starlight S|Chevrolet Captiva EV]]||2025|| ||Assembled from semi-knockdown kits imported from China under contract for GM. Production for GM began on December 3, 2025 with the Spark EUV. Production for non-GM brands is also expected. The plant is the former [[w:Troller|Troller]] plant that was bought by Ford in 2007 and closed in 2021. The plant is now operated by Comexport.

|-

|&amp;nbsp;||[[SaryarkaAvtoProm]]/&lt;br&gt;Allur Automobile Plant||[[w:Kostanay|Kostanay]]||[[w:Kazakhstan|Kazakhstan]]||[[w:Chevrolet Cobalt#Second generation (2011)|Chevrolet Cobalt]], [[w:Chevrolet Onix#Second generation (2019)|Chevrolet Onix]], [[w:Chevrolet Tracker (2019)|Chevrolet Tracker]]||2017|| ||Built under contract by SaryarkaAvtoProm for GM &amp; UzAuto Motors.  

Past models: [[w:Chevrolet Malibu#Ninth generation (2016)|Chevrolet Malibu]], [[w:Chevrolet Aveo (T200)|Chevrolet Nexia]], [[w:Chevrolet Niva|Chevrolet Niva]], [[w:Suzuki Carry#Daewoo Damas|Chevrolet Damas/Labo]], [[w:Chevrolet Aveo (T200)|Ravon Nexia R3]] 

|- 

|S||[[w:Shyft Group|Shyft Group]] - Charlotte plant||[[w:Charlotte, Michigan|Charlotte, Michigan]]||[[w:United States|United States]]||[[w:Isuzu Elf|Chevrolet Low Cab Forward 3500/4500/5500 gas]] (2016-)&lt;br /&gt;[[w:Isuzu F-Series|Chevrolet Low Cab Forward 6500XD &amp; 7500XD]] (2018- &amp; 2023-)&lt;br /&gt;[[w:Isuzu N-Series|Isuzu N-Series gas]] (2012-)&lt;br /&gt;[[w:Isuzu F-Series|Isuzu FTR/FVR]] (2018- &amp; 2023-)||1961||&amp;nbsp;||[[w:Shyft Group|Shyft Group]] plant. Built under contract for Isuzu and GM. 

|}

== Former factories == 

 
{| class=&quot;wikitable sortable&quot; style=&quot;font-size:90%&quot; 
! style=&quot;width:20px;&quot;|VIN 
! style=&quot;width:60px;&quot;| Name 
! style=&quot;width:20px;&quot;| City/State 
! style=&quot;width:20px;&quot;| Country 
! style=&quot;width:90px;&quot; class=&quot;unsortable&quot; | Products 
! style=&quot;width:10px;&quot;| Opened 
! style=&quot;width:10px;&quot;| Idled 
! style=&quot;width:190px;&quot; class=&quot;unsortable&quot; |Comments

|- 

|&amp;nbsp;||AC Electronics||[[w:Oak Creek, Wisconsin|Oak Creek, Wisconsin]]||[[w:United States|United States]]||Automotive Electronics; Avionics, precision guidance systems, &amp; electro-mechanical devices for military use and space exploration (Apollo program) ||1948||1999||Located at 7929 S. Howell Ave. First known as GM's Electronics Division. In 1965, the Milwaukee Operations became known as AC Electronics Division of GM. In 1970, the division merged with Delco Radio and became known as Delco Electronics Division. Spun off with Delphi Automotive Systems (Delphi Electronics &amp; Safety) in 1999. Closed by Delphi in 2008. Is now Drexel Town Square, a retail, commercial, residential and civic development.

|- 

|&amp;nbsp;||[[w:ACDelco#AC Spark Plug Division|AC Spark Plug Division]]||[[w:Flint, Michigan|Flint, Michigan]]||United States||AC Spark Plugs||1929||1975||Located on Industrial Ave at Harriet St. Built in 1909. Champion Ignition Co. moved here from their original location on the 3rd floor of a Buick building on Hamilton Ave. that they used from 1908. This complex was expanded multiple times and was on both sides of Industrial Ave. with 2 overhead walkways connecting the 2 sides. Champion Ignition Co. changed its name to AC Spark Plug in 1922. After founder Albert Champion died in 1927, GM took over AC Spark Plug in 1929. It became a GM division in 1933. Production gradually moved to the Flint East complex until the Industrial Ave. complex closed in 1975. Demolished in 1975-76. Site later used by Buick for parking as it was next to the Buick City complex.

|- 

|&amp;nbsp;||[[w:Flint East|AC Spark Plug Flint East]]||[[w:Flint, Michigan|Flint, Michigan]]||United States||Components (spark plugs, dashboard components such as instrument clusters, fuel system components, air/oil/fuel filters, and fuel pumps)||1929||1999||Located at 1300 North Dort Highway. (Now referred to as 2926 Davison Road, which is the north side instead of the west side of the property.) Purchased by AC Spark Plug in 1925. Plant previously belonged to [[w:Dort Motor Car Company|Dort Motor Car Company]], which went out of business in 1924. Initially produced all products other than spark plugs that were made by AC Spark Plug Co. After founder Albert Champion died in 1927, GM took over AC Spark Plug in 1929. It became a GM division in 1933. Production gradually moved from the old Industrial Ave. complex to the Flint East complex until the Industrial Ave. complex closed in 1975. Became known as Flint East in 1987, when AC took over the &quot;Chevy in the Hole&quot; complex from Chevrolet on Flint's west side, which became known as Flint West. Became AC Rochester in 1988 when AC Spark Plug Division merged with Rochester Products Division. AC Rochester initially had its world headquarters here, just as AC Spark Plug had before the merger. Subsequently, AC Rochester headquarters moved to the Great Lakes Technology Center in the old Flint Fisher Body plant. In 1994, AC Rochester merged with Delco Remy and became AC Delco Systems. Grouped under GM's Delphi Automotive Systems subsidiary in 1995. Spun off with [[w:Delphi Corporation|Delphi Corporation]] in 1999. GM supplied the UAW workers from 2007 under agreement with Delphi and the UAW. Closed by Delphi in 2013.  

|- 

|&amp;nbsp;||[[w:ACDelco#AC Spark Plug Division|AC Spark Plug]]||[[w:Sioux City, Iowa|Sioux City, Iowa]]||[[w:United States|United States]]||[[w:Throttle#Throttle body|Throttle Body Fuel Injection Systems]]||1981||1993||Located at 1805 Zenith Drive. Formerly a Zenith Radio Factory. Now the headquarters of Bomgaars Supply, Inc.

|- 

|&amp;nbsp;||[[w:ACDelco#AC Spark Plug Division|AC Spark Plug]]||[[w:Wichita Falls, Texas|Wichita Falls, Texas]]||United States||AC Air Filters||1972||1999||Located at 8600 Interstate 44 Service Rd. Spun off with Delphi Automotive Systems in 1999. Closed by Delphi in 2008. Now owned by Panda Biotech.

|-  

|&amp;nbsp;||[[w:ACDelco#AC Spark Plug Division|AC Spark Plug Overseas Corp. - Kirkby plant]]||[[w:Kirkby|Kirkby]], [[w:Merseyside|Merseyside]], [[w:England|England]]||[[w:United Kingdom|United Kingdom]]||Instrument panels, Gauges, Fuel pumps, Fuel/temperature senders, Oil pressure switches, Radiator caps, Thermostats||1958||?||Plant is near Liverpool. Located on Moorgate Road. Kirkby was originally part of the AC-Delco division of GM Ltd. When the Kirkby plant opened in 1958, production of fuel pumps, thermostats, and instruments was moved there from the Dunstable components plant. In 1979, Kirkby became aligned with AC Spark Plug in the US. In 1982, GM Ltd. was dissolved and the Kirkby plant became part of AC Spark Plug Overseas Corp., part of GM Overseas Corp.

|-  

|&amp;nbsp;||[[w:ACDelco#AC Spark Plug Division|AC Spark Plug Overseas Corp. - Southampton plant]]||[[w:Southampton|Southampton]], [[w:Hampshire|Hampshire]], [[w:England|England]]||[[w:United Kingdom|United Kingdom]]||Air filter elements, Oil filters, Fuel filters, Catalytic converters||1952||?|| Located on West Bay Road in the New Dock area of Southampton. Originally opened in 1938 as a vehicle assembly plant making Chevrolets (See listing for &quot;GM Ltd.&quot;). Plant acquired by GM Ltd. in 1951. Southampton was originally part of AC-Sphinx Plug Co., a division of GM Ltd. In 1952, AC-Sphinx Plug Co. was renamed AC-Delco division of GM Ltd. When the Southampton plant opened in 1952, production of automotive filters (air filters, fuel filters) was moved there from the Dunstable components plant. In 1979, Southampton became aligned with AC Spark Plug in the US. In 1982, GM Ltd. was dissolved and the Southampton plant became part of AC Spark Plug Overseas Corp., part of GM Overseas Corp.

|-

|&amp;nbsp;||Allison,&lt;br&gt; [[w:Allison Transmission|Allison Transmission]], Allison Gas Turbine||[[w:Indianapolis|Indianapolis]], Indiana||United States||Allison Transmissions,&lt;br&gt; Engines for airplanes &amp; helicopters,&lt;br&gt; Bearings and Gears||1929||2007||Located at 4700 W. 10th St. Founded in 1915 as Speedway Team Co. In 1920, it was renamed Allison Engineering Co. Acquired by GM in 1929, it became the Allison Division of GM. GM began designing the CD-850 transmission for tracked military vehicles in 1941; the design was completed in 1944 and Allison was awarded the contract to manufacture the prototypes. In February 1945, General Motors formed the Allison Transmission Engineering Section. In 1946, GM divided the division into 2 sections: Aircraft Operations and Transmission Operations. In 1970, Allison Division merged with the Detroit Diesel Engine Division to become the Detroit Diesel-Allison Division. In 1983, the aviation turbine engine operations were separated out to form a separate division called the Allison Gas Turbine Division. In 1987, the transmission operations are separated out to form the Allison Transmission Division. Allison Gas Turbine was sold in a management buyout in 1993 becoming the Allison Engine Company. [[w:Allison Engine Company|Allison Engine Company]] was then sold in 1995 to [[w:Rolls-Royce Holdings|Rolls-Royce PLC]]. GM sold Allison Transmission in 2007 to private equity groups Carlyle Group &amp; Onex Corp., becoming Allison Transmission Inc. Allison went public as Allison Transmission Holdings Inc. in 2012, trading on the New York Stock Exchange.

|- 

|&amp;nbsp;||Cadillac Amsterdam Street plant||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||[[w:Cadillac|Cadillac]]s||1903||1920||Cadillac's first volume production plant. Located at 450 Amsterdam Street, at the intersection with Cass Avenue. Rebuilt in 1904 after a fire destroyed the original plant. This plant predated Cadillac being part of GM. Replaced by the Clark Street plant in 1921. 

|- 

|5 (Plant 2)&lt;br /&gt;&lt;br /&gt; 6 (Plant 1)&lt;br /&gt;&lt;br /&gt;9 (Pre-1976)||Antwerp||[[w:Antwerp|Antwerp]]||[[w:Belgium|Belgium]]||[[w:Opel Astra|Opel Astra]]/[[w:Vauxhall Astra|Vauxhall Astra]]&lt;br /&gt;[[w:Opel Astra#Astra H (A04; 2004)|Opel/Vauxhall Astra GTC &amp; OPC/VXR (H)]]&lt;br /&gt;[[w:Opel Astra#TwinTop|Opel/Vauxhall Astra TwinTop]]&lt;br /&gt;[[w:Opel Astra#Saturn Astra|Saturn Astra]] (2008 &amp; in Canada '09)&lt;br /&gt;[[w:Holden Astra#Fourth generation (TS; 1998)|Holden Astra (TS)]]&lt;br /&gt;[[w:Holden Astra#Fifth generation (AH; 2004)|Holden Astra (AH)]] ||1925||2010||Originally known as GM Continental SA, then as Opel Antwerp from 1994-2004, &amp; finally as GM Belgium from 2004 on. The original plant was an ex-abbey on Fortuinstraat. In 1926, production moved to an old velodrome on the corner of St. Laureystraat &amp; Haantjeslei. In 1929, production moved to a site in the port of Antwerp near the Albert dock. The site at the port was destroyed by bombing raids in World War II. Production temporarily moved back to the velodrome from 1946-1953. In 1953, a new plant opened on the Noorderlaan which would later come to be known as Plant 1. In 1967, a second plant opened about 6.2 miles (10&amp;nbsp;km) north of the Noorderlaan plant near the Churchill dock. This was called Plant 2. In August 1988, production was consolidated in Plant 2 and Plant 1 was used as a parts warehouse until 1992 and the property was then sold. Plant 2 ended production in December 2010. First vehicle off the line was a Chevrolet. Assembled Opel &amp; Vauxhall cars, Bedford trucks and American GM brands (Chevrolet, Pontiac, Oldsmobile, Buick, &amp; Cadillac) from CKD kits. Also built the [[w:Ranger (automobile)#Europe|Ranger]]. The plant finally closed its doors on December 17, 2010, about two days after last Opel car rolled off the assembly line.&amp;nbsp;&lt;br /&gt;Past models: [[w:Chevrolet Camaro (first generation)|Chevrolet Camaro]] (first generation from CKD kits)&lt;br /&gt;[[w:Chevrolet Corvair|Chevrolet Corvair]] (from CKD kits supplied from Oshawa)&lt;br /&gt;[[w:Opel Ascona|Opel Ascona]]&lt;br /&gt;[[w:Opel Kadett|Opel Kadett]]&lt;br /&gt;[[w:Opel Manta|Opel Manta]]&lt;br /&gt;[[w:Opel Olympia|Opel Olympia]]&lt;br /&gt;[[w:Opel Rekord|Opel Rekord]]&lt;br /&gt;[[w:Opel Vectra|Opel Vectra]]&lt;br /&gt;[[w:Vauxhall Cresta|Vauxhall Cresta]]&lt;br /&gt;[[w:Vauxhall Velox|Vauxhall Velox]]&lt;br /&gt;[[w:Vauxhall Victor|Vauxhall Victor]]  

|- 

|&amp;nbsp;||[[w:General Motors de Argentina|General Motors de Argentina]]||[[w:San Telmo, Buenos Aires|San Telmo]] and [[w:Barracas, Buenos Aires|Barracas]] in [[w:Buenos Aires|Buenos Aires]] &amp; [[w:San Martín, Buenos Aires|San Martin]]||[[w:Argentina|Argentina]]||Chevrolet (cars and trucks) including [[w:Chevrolet 400|Chevrolet 400]], [[w:Chevrolet Chevy Malibu|Chevrolet Chevy]], &amp; [[w:Chevrolet C/K|Chevrolet C/K]] &lt;br /&gt;[[w:Chevrolet C/K (second generation)#Medium-duty trucks|Chevrolet C-50/C-60/C-70]]&lt;br /&gt;[[w:Chevrolet/GMC B series|Chevrolet B-60 bus chassis]]&lt;br /&gt; Oldsmobile &lt;br /&gt;[[w:Opel K 180|Opel K 180]]&lt;br /&gt;[[w:Bedford TJ|Bedford TJ]]&lt;br /&gt;[[w:Chevrolet 153 4-cylinder engine#Argentina|Chevrolet 153 4-cylinder]]&lt;br /&gt;[[w:Chevrolet Turbo-Thrift engine|Chevrolet Turbo-Thrift engine]]&lt;br /&gt;Bedford diesel engines||1925 (San Telmo)&lt;br /&gt;1928 (Barracas)&lt;br /&gt;1940 (San Martin plant)||1978 (San Martin plant)||Other GM brands manufactured included GMC, Opel, and Bedford trucks along with Pontiac, Oakland, Marquette, Buick, LaSalle, Cadillac, Opel, and Vauxhall passenger cars.&lt;ref&gt;{{cite web|url=https://history.gmheritagecenter.com/wiki/index.php/GM_Argentina|title=GM Argentina}}&lt;/ref&gt; Also Frigidaire refrigerators.  

|- 

|&amp;nbsp;||[[w:Aymesa|Aymesa]]||[[w:Quito, Ecuador|Quito]]||[[w:Ecuador|Ecuador]]|| ||1973||1999 (Last GM production)|| First automotive assembler in Ecuador. GM bought 36.95% of AYMESA in 1982 &amp; increased its stake to 45.9% in 1984. GM sold off its stake in 1999 and switched to using OBB as its Ecuadorian partner. Aymesa now assembles vehicles for Kia and Hyundai.

Past models: [[w:Opel Corsa#Corsa B (S93; 1993)|Chevrolet Corsa]]&lt;br /&gt;[[w:Suzuki Cultus#First generation (1983)|Suzuki Forsa]]&lt;br /&gt;[[w:Suzuki Cultus#Second generation (1988)|Suzuki Forsa II/Chevrolet Swift]]&lt;br /&gt;[[w:General Motors T platform (1973)|Chevrolet San Remo]]&lt;br /&gt;Aymesa Gacela&lt;br /&gt;Aymesa Condor&lt;br /&gt;[[w:Bedford HA#The BTV|Aymesa Andino]]&lt;br /&gt;Aymesa Amigo 

|- 

|3 (since 1993)&lt;br /&gt;A (before 1993)||Azambuja||[[w:Azambuja|Azambuja]]||[[w:Portugal|Portugal]]||[[w:Opel Combo#Kadett Combo (Combo A; 1986)|Opel Kadett Combo A/Bedford &amp; Vauxhall Astravan &amp; Astramax]]&lt;br /&gt;[[w:Opel Combo#Combo B (1993-2001)|Opel/Vauxhall/Holden Combo]] B&lt;br /&gt;[[w:Opel Combo#Combo C (2001-2012)|Opel/Vauxhall/Holden Combo]] C||1963||2006||Past models:&lt;br /&gt;[[w:Opel Corsa#Corsa Van|Opel Corsavan]]&lt;br /&gt; [[w:Opel Kadett|Opel Kadett]]&lt;br /&gt;[[w:Opel Rekord|Opel Rekord]]&lt;br /&gt;[[w:Vauxhall Victor|Vauxhall Victor]]&lt;br /&gt;[[w:Vauxhall Viva|Vauxhall Viva]]&lt;br /&gt;[[w:Bedford HA#The BTV|Amigo]]&lt;br /&gt;[[w:Bedford CF|Bedford CF]]&lt;br /&gt;[[w:Bedford TJ|Bedford TJ]]&lt;br /&gt;[[w:Bedford TK|Bedford TK]]&lt;br /&gt;Various Opel, Vauxhall, &amp; Bedford models. 

|- 

|B &lt;br /&gt;(1953-1964 [[w:Chevrolet|Chevrolet]]&lt;br /&gt;and 1964 [[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt; and 1965-2005)&lt;br /&gt;&lt;br /&gt;14 (1935-1952 [[w:Chevrolet|Chevrolet]]) &lt;br /&gt;&lt;br /&gt; 7 (1964 [[w:Buick|Buick]])||[[w:Baltimore Assembly|Baltimore Assembly]]||[[w:Baltimore|Baltimore]], [[w:Maryland|Maryland]]||United States||[[w:Chevrolet Astro|Chevrolet Astro]] (1985-2005)&lt;br /&gt;[[w:Chevrolet Astro|GMC Safari]] (1985-2005) ||1935||2005||Located at 2122 Broening Highway. Production began in March 1935 (March 11 for trucks and March 26 for cars). Was part of the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Baltimore Assembly began making Pontiac and Buick passenger cars for 1964. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were gradually transferred to the GM Assembly Division which replaced the BOP Assembly Division in 1965. Baltimore Assembly joined the GM Assembly Division in 1968. During WWII, the Chevrolet side of the plant operated as a military parts depot where parts were received, processed, and packaged for shipment around the world. It also built 2,650 [[w:GMC CCKW 2½-ton 6×6 truck|GMC CCKW 6x6 trucks]]. The Fisher Body side of the plant became part of GM's Eastern Aircraft Division and assembled the rear fuselage, tail assembly, &amp; all control surfaces for Grumman carrier-based aircraft. Car production ended on March 31, 1984. Converted to a Truck and Bus Group assembly plant for 1985. Production restarted in August 1984. Closed on May 13, 2005. Baltimore Assembly produced over 12 million vehicles. Demolished. Now the Chesapeake Commerce Center and an Amazon distribution center.&lt;br /&gt; 

Past models:&lt;br /&gt; [[w:Chevrolet Standard Six|Chevrolet Standard Six]]&lt;br /&gt;[[w:Chevrolet Master|Chevrolet Master]]&lt;br /&gt;[[w:Chevrolet Deluxe|Chevrolet Deluxe]]&lt;br /&gt;[[w:Chevrolet Fleetmaster|Chevrolet Fleetmaster]]&lt;br /&gt;[[w:Buick Gran Sport|Buick GS]] (1965-1968),&lt;br /&gt; [[w:Buick Skylark|Buick Skylark]] (1964-68),&lt;br /&gt; [[w:Buick Special|Buick Special]] (1964-67), [[w:Chevrolet 150|Chevrolet 150]] (1953-57), [[w:Chevrolet 210|Chevrolet 210]] (1953-57), [[w:Chevrolet AK Series|Chevrolet AK Series]], [[w:Chevrolet Advance Design|Chevrolet Advance Design]] (1947-1955), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1950-1963), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1958-1963), [[w:Chevrolet C/K|Chevrolet C/K]] (1960-1980), [[w:Chevrolet Chevelle|Chevrolet Chevelle]] (1964-1977), [[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958), [[w:Chevrolet El Camino|Chevrolet El Camino]] (1959-1960, 1964-1977), [[w:Chevrolet Impala|Chevrolet Impala]] (1958-1963), [[w:Chevrolet Malibu#Fourth generation (1978)|Chevrolet Malibu]] (1978-1983), [[w:Chevrolet Monte Carlo|Chevrolet Monte Carlo]] (1970-1984), [[w:Chevrolet Nomad|Chevrolet Nomad]] (1955-1957), [[w:Chevrolet Suburban|Chevrolet Suburban]] (1957, 1962, 1964-1966), [[w:Chevrolet Task Force|Chevrolet Task Force]] (1955-1959), [[w:Chevrolet C/K (second generation)|GMC C/K (Action Line)]] (1967-1972), [[w:Chevrolet C/K (third generation)|GMC C/K (Rounded Line)]] (1973-1980), [[w:GMC Sprint|GMC Sprint]] (1971-1977), [[w:Pontiac Bonneville#Seventh generation (1982–1986)|Pontiac Bonneville]] (1983-1984), [[w:Pontiac Grand Prix#Fifth generation (1978–1987)|Pontiac Grand Prix]] (1983-1984), [[w:Pontiac GTO|Pontiac GTO]] (1964-1970), [[w:Pontiac LeMans|Pontiac LeMans]] (1964-1970, 1978-1981), [[w:Pontiac Tempest|Pontiac Tempest]] (1964-1970) 

|- 

|&amp;nbsp;||[[w:Baltimore Transmission|Baltimore Transmission]]||[[w:White Marsh, Maryland|White Marsh]], [[w:Maryland|Maryland]]||United States||Allison 1000 Series transmissions: [[w:Chevrolet Silverado|Silverado HD]], [[w:GMC Sierra|Sierra HD]]&lt;br /&gt;Hybrid 2-mode transmissions ([[w:Global Hybrid Cooperation|2ML70]]): [[w:Chevrolet Tahoe#Third generation (2007)|Chevrolet Tahoe Hybrid]], [[w:Chevrolet Tahoe#Third generation (2007)|GMC Yukon Hybrid]], [[w:Cadillac Escalade#Hybrid|Cadillac Escalade Hybrid]], [[w:Chevrolet Silverado#Second-generation Silverado / third-generation Sierra (GMT900; 2007)|Chevrolet Silverado Hybrid]], [[w:Chevrolet Silverado#Second-generation Silverado / third-generation Sierra (GMT900; 2007)|GMC Sierra Hybrid]]&lt;br /&gt;Electric motor (MME) &amp; final-drive unit (1ET35) for [[w:Chevrolet Spark#Spark EV|Chevy Spark EV]]&lt;br /&gt;Torque converters for 6-speed rwd automatic transmissions||2000||2019||Located at 10301 Philadelphia Road. Originally part of Allison Transmission.  Became a GM Powertrain facility in 2004. Name changed to Baltimore Operations in 2012 with the addition of the Electric Motor Plant built next to the existing Transmission Plant. Closed in 2019.&lt;ref&gt;{{Cite web|url=https://gmauthority.com/blog/2019/04/gm-baltimore-employees-irate-over-plant-closure/|title = GM Baltimore Employees Irate over Plant Closure|author=Anthony Alaniz|publisher=GMAuthority.com|date = 19 April 2019}}&lt;/ref&gt; Now called White Marsh Interchange Park, a complex of 9 new one-story buildings of office and warehouse space that replaces the previous GM plant which has been demolished.

|- 

|T||[[w:Bedford Dunstable plant|Bedford Dunstable plant]]||[[w:Dunstable|Dunstable]], [[w:Bedfordshire|Bedfordshire]], [[w:England|England]]||[[w:United Kingdom|United Kingdom]]||[[w:Bedford Vehicles|Bedford trucks and buses]] including:&lt;br&gt; [[w:Bedford S type|Bedford S series]]&lt;br /&gt;[[w:Bedford TA|Bedford TA/TD]]&lt;br /&gt;[[w:Bedford TJ|Bedford TJ]]&lt;br /&gt;[[w:Bedford TK|Bedford TK/KM]]&lt;br /&gt;[[w:Bedford TL|Bedford TL]]&lt;br /&gt;[[w:Bedford TM|Bedford TM]]&lt;br /&gt;[[w:Bedford SB|Bedford SB]]&lt;br /&gt;[[w:Bedford VAL|Bedford VAL]]&lt;br /&gt;[[w:Bedford VAM|Bedford VAM]]&lt;br /&gt;[[w:Bedford VAS|Bedford VAS]]&lt;br /&gt;[[w:Bedford Y series|Bedford Y series]]&lt;br /&gt;Bedford gas &amp; diesel engines||1942 (for wartime production)&lt;br&gt;&lt;br&gt; 1955 (for civilian production)||1987||Was located on Boscombe Road. Bedford truck and bus production was moved to Dunstable from Luton in 1955. GM sold the Bedford heavy truck business to AWD Trucks in 1987. AWD Trucks went bankrupt in 1992. Parts of the site were demolished in 1993. More was demolished in 1997. The remainder was demolished in 2005. The [[w:Commer|Commer]] plant was located across Boscombe Road in Dunstable from the 1960's.

|- 

|&amp;nbsp;||Bombay||[[w:Bombay|Bombay]], [[w:Maharashtra|Maharashtra]]||[[w:India|India]]||[[w:Chevrolet|Chevrolet]] cars, trucks, &amp; buses||1928||1954||The first automobile assembly plant in India. The original GM India Ltd. was closed in 1954.  

|- 

|12 (Buffalo Assembly from 1928)||[[w:Buffalo Assembly|Buffalo Assembly]]/&lt;br /&gt;Buffalo Gear &amp; Axle||[[w:Buffalo, New York|Buffalo, New York]]||United States||[[w:Chevrolet Superior|Chevrolet Superior]]&lt;br /&gt;[[w:Chevrolet Series AA Capitol|Chevrolet Series AA Capitol]]&lt;br /&gt;[[w:Chevrolet Series AB National|Chevrolet Series AB National]]&lt;br /&gt;[[w:Chevrolet Series AC International|Chevrolet Series AC International]]&lt;br /&gt;[[w:Chevrolet Series AD Universal|Chevrolet Series AD Universal]]&lt;br /&gt;[[w:Chevrolet Series AE Independence|Chevrolet Series AE Independence]]&lt;br /&gt;[[w:Chevrolet Series BA Confederate|Chevrolet Series BA Confederate]]&lt;br /&gt;[[w:Chevrolet Series CA Eagle / Master|Chevrolet Series CA Eagle / Master]]&lt;br /&gt;[[w:Chevrolet Master|Chevrolet Master]]&lt;br /&gt;[[w:Chevrolet Standard Six|Chevrolet Standard Six]]&lt;br /&gt;[[w:Chevrolet Suburban|Chevrolet Suburban]]&lt;br /&gt; Axles, drivetrain components||1923||1994||Located at 1001 E. Delavan Ave. Built cars until World War II &amp; was then converted to make axles. Operation was renamed Saginaw Gear and Axle in 1984. Sold to [[w:American Axle|American Axle]] in 1994. All operations ended in 2007 &amp; the factory closed. Called the Historic American Axle Building. Purchased by Viridi in 2018. 

|- 

|H (1965-1999)&lt;br /&gt;&lt;br /&gt; 1 (1938-1964 [[w:Buick|Buick]])||[[w:Buick City|Buick City]]||[[w:Flint, Michigan|Flint, Michigan]]||United States||[[w:Buick LeSabre|Buick LeSabre]] (1959-1999)&lt;br /&gt;[[w:Buick Park Avenue|Buick Park Avenue]] (1994-1996)&lt;br /&gt;[[w:Oldsmobile 88|Oldsmobile 88]] (1987, 1989-1995)&lt;br /&gt;[[w:Pontiac Bonneville#Ninth generation (1992–1999)|Pontiac Bonneville]] (1996-1999)||1904||1999||This was Buick's home plant. It predated the founding of GM in 1908. This is the part of the Buick factory complex south of Leith St. stretching south to E. Hamilton Ave. The complete complex, including both North and South portions totals 412,947 acres. The original factory was at one time the largest in the world and was completely vertically integrated, making nearly every component within the complex. During WWII, Buick built [[w:M18 Hellcat|M18 Hellcat]] tanks &amp; [[w:M39 armored utility vehicle|M39 armored utility vehicles]] here. The plant was converted to build unibody, fwd cars for 1986 instead of the previous body-on-frame, rwd cars. The modernized plant was renamed Buick City. The factory closed in June 1999. Last car built was a 1999 Buick LeSabre. Demolished by 2002. The site of Buick's administration building, 902 E. Hamilton Ave., is now a seating plant owned by Lear Corp., which opened in 2018. It supplies seats to GM's nearby Flint Truck Assembly Plant as well as GM's Fort Wayne Assembly Plant in Indiana. A large piece of the property is now being redeveloped as Flint Commerce Center.&lt;br&gt; Past models: [[w:Buick Centurion|Buick Centurion]] (1971–1973),&lt;br&gt; [[w:Buick Century|Buick Century]] (1936-42, 1954-1958, 1973-1981), [[w:Buick Electra|Buick Electra]] (1959-1984), [[w:Buick Estate|Buick Estate]] (1940-64, 1970-76), [[w:Buick GS|Buick GS]] (1965-1972), [[w:Buick Invicta|Buick Invicta]] (1959-1963), [[w:Buick Limited|Buick Limited]] (1936-42, 1958), [[w:Buick Regal|Buick Regal]] (1973-1985), [[w:Buick Riviera|Buick Riviera]] (1963-1978), [[w:Buick Roadmaster|Buick Roadmaster]] (1936-58), [[w:Buick Skylark#1953–1954|Buick Skylark]] (1953-1954), [[w:Buick Skylark|Buick Skylark]] (1961-72), [[w:Buick Special|Buick Special]] (1936-58, 1961-69), [[w:Buick Sport Wagon|Buick Sport Wagon]] (1964-1971), [[w:Buick Super|Buick Super]] (1940-1958), [[w:Buick Wildcat|Buick Wildcat]] (1963-1970) [[w:Marquette (automobile)#Buick brand|Marquette]] (1930), [[w:Chevrolet Caprice#Third generation (1977–1990)|Chevrolet Caprice]] (1984-1985), [[w:Chevrolet Impala#Sixth generation (1977–1985)|Chevrolet Impala]] (1984-1985),&lt;br&gt; [[w:Oldsmobile Cutlass Supreme#Fourth generation (1978–1988)|Oldsmobile Cutlass Supreme]] (1985). 

|- 

|&amp;nbsp;||Cadillac Stamping||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||Stamped body parts for Cadillac||1956||1987||Located at 9501 Conner St. Originally built by Clayton &amp; Lambert Manufacturing Company for their Knodell Division. Sold to Hudson Motor Car Company in 1925. Made bodies for Hudson. Bought by GM in 1956. Demolished in 2021. Site used by [[w:Lear Corp.|Lear Corp.]] to make seats to supply GM's Factory Zero plant.  

|- 

|&amp;nbsp;||[[w:Cartercar|Cartercar]]||[[w:Pontiac, Michigan|Pontiac]], [[w:Michigan|Michigan]]||United States||Cartercar automobiles||1909||1915||Located on Franklin Rd. where Franklin turns into Linfere St. which then intersects with Brush St. This factory previously belonged to Pontiac Spring &amp; Wagon Works. Cartercar moved into this factory in 1908. Cartercar was purchased by GM on October 26, 1909. Cartercar was known for its [[w:Friction drive|friction drive transmission]]. GM closed Cartercar in 1915. There was then talk that GM would build a 6-cylinder Oakland model at this factory but it doesn't seem to have ever happened. GM sold the factory to Olympian Motors Company in 1917, which built Olympian cars there from 1917-1919. In 1920, the factory was sold to Friend Motors Corporation. Initially, Friend Motors Corporation continued production of Olympian cars and then switched to production of new Friend cars in 1921 but production ended with less than 50 cars built and Friend Motors went out of business. In 1922, Friend Motors owner Otis Friend filed for bankruptcy and factory ownership was transferred to Gotham National Bank in a foreclosure sale. The next occupant of the plant was the Wolverine Manufacturing Company which built furniture. Later, it was used as an agricultural supply warehouse. Most of the complex is gone but one building remains at 20 Franklin Rd. It was last occupied by House of Bedrooms, a furniture store. One side of the building still says &quot;The Wolverine&quot; at the top. The other side that faces Brush St. still says &quot;Pontiac Spring &amp; Wagon Works&quot; right under what were the highest row of windows.

|- 

|&amp;nbsp;||Chevrolet Gear &amp; Axle||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||Axles, gears, other components||1919||1994||Located at 1840 Holbrook Ave. Absorbed the former Northway engine plant on Holbrook Ave. in 1926 when Northway was liquidated by GM. Straddles the border of [[w:Detroit|Detroit]] and [[w:Hamtramck, Michigan|Hamtramck, Michigan]]. Sold to [[w:American Axle|American Axle]] &amp; Manufacturing Inc. in 1994. Closed in 2012, demolished in 2013. 

|- 

|&amp;nbsp;||Fisher Body - Chicago Metal Fabrication||[[w:Willow Springs, Illinois|Willow Springs, Illinois]]||United States||Stampings (such as floorpans) for GM vehicles||1953||1989||Located at 79th Street and Willow Springs Road. Buick produced J65-B-3 jet engines here for the [[w:Republic F-84F Thunderstreak|Republic F-84F Thunderstreak]]/RF84-F Thunderflash for use in the Korean War. Plant was associated with Buick-Oldsmobile-Cadillac Group but made body parts for all 5 of GM's passenger car divisions. Sold to [[w:United Parcel Service|UPS]].  

|- 

|&amp;nbsp;||[[w:General Motors de Chile|General Motors de Chile]]||[[w:Arica|Arica]]||[[w:Chile|Chile]]||[[w:Isuzu Faster#Second generation (1980–1988)|Chevrolet LUV]]&lt;br /&gt;[[w:Isuzu Faster#Third generation (TF; 1988–2002)|Chevrolet LUV (TF)]]&lt;br /&gt;[[w:Isuzu Faster#South America 2|Chevrolet Grand LUV (TF)]]&lt;br /&gt;[[w:Isuzu D-Max#First generation (RA, RC; 2002)|Chevrolet D-Max]]||1968&lt;br&gt;1974||1971&lt;br&gt;2008||Originally belonged to Alberto Avayú y Cía. S.A.I.C. (part of Empresas Indumotora) which built vehicles under license for GM beginning in 1960. Avayú built the [[w:Chevrolet Chevy II / Nova|Chevrolet Chevy II / Nova]], [[w:Chevrolet C/K (first generation)|Chevrolet C-1434]], [[w:Opel Rekord|Opel Rekord]], [[w:Opel Rekord|Opel Furgón (van)]]. GM bought the plant in 1968. Built [[w:Chevrolet Chevy II / Nova|Chevrolet Chevy II / Nova]] &amp; [[w:Chevrolet C/K (second generation)|Chevrolet C10]]. GM left Chile at the end of 1971 but returned in 1974. Past models: [[w:Chevrolet C/K (third generation)|Chevrolet C-10 and C-30]], [[w:Chevrolet C/K|Chevrolet C/K]] medium duty truck, [[w:Chevrolet Chevette#Latin America|Brazilian Chevrolet Chevette]], and Japanese [[w:Isuzu Aska#South America (Chile, Ecuador)|Chevrolet Aska]] 

|- 

|&amp;nbsp;||Fisher Body - Cleveland Division||[[w:Cleveland|Cleveland]], [[w:Ohio|Ohio]]||United States||Bodies for GM vehicles||1921||1983||Located at Coit Road and E. 140th Street. Founded as Fisher Body Ohio Co. GM bought 60% of Fisher Body in 1919 and the remaining 40% in 1926. Began by building bodies for Chandler, Cleveland (a subsidiary of Chandler), Chrysler, and the Oakland &amp; Chevrolet divisions of GM. After 1926, it only made bodies for GM. In 1936, the plant switched from making whole bodies to doing metal trim and fabrication due to a decrease in demand for cars due to the Depression. Production of auto bodies resumed after World War II. Built bodies for low-volume models like the 55-57 Chevy Nomad and convertible models. In the 1970's, it built large stamping dies and upholstery &amp; trim sets. Closed in August 1983 as a metal fabrication plant. 

|- 

|&amp;nbsp;||[[w:Cleveland Diesel Engine Division|Cleveland Diesel Engine Division]]||[[w:Cleveland|Cleveland]], [[w:Ohio|Ohio]]||United States||Heavy-duty diesel engines for locomotives, marine use (ships and submarines), and stationary use||1930||1962||Founded by Alexander Winton, company began operation in Nov. 1912 as the Winton Gas Engine &amp; Mfg. Co. at 2116 W. 106th St. Renamed the Winton Engine Works in 1916 and later as the Winton Engine Company. GM bought Winton Engine Co. on June 20, 1930 and renamed it Winton Engine Corp. on June 30, 1930. In 1938, it was renamed Cleveland Diesel Engine Division. In January 1941, locomotive engine development and production was transferred to GM's Electro-Motive Division. Marine and stationary diesel engines were still handled by Cleveland Diesel Engine Division. In the 1950s, Cleveland Diesel Engine expanded with the acquisition of plants at 2160 W. 106th St. and 8200 Clinton Rd. The advent of nuclear-powered submarines in the 1950's reduced the US Navy's need for the large diesel engines produced by Cleveland Diesel and in 1962, GM closed down the division and transferred any remaining engine production to Electro-Motive Division's La Grange plant in McCook, Illinois. 

|-

|&amp;nbsp;||[[w:GM Colmotores|GM Colmotores]]||[[w:Bogotá|Bogotá]]||[[w:Colombia|Colombia]]||Products from [[w:GM do Brasil|GM do Brasil]]: [[w:Chevrolet Onix#First generation (2013)|Chevrolet Joy]] 

&lt;br /&gt;Products from [[w:Isuzu|Isuzu]]: [[w:Isuzu Forward|Chevrolet F-Series Bus]], [[w:Isuzu Forward|Chevrolet F-Series truck]], [[w:Isuzu Elf|Chevrolet N-Series Bus]], [[w:Isuzu Elf|Chevrolet N-Series truck]], Chevrolet LV-series Bus 

||1979||2024||Founded in 1956 as Colmotores, production began in 1962 with the [[w:Austin Motor Company|Austin]] brand, then switched to the [[w:Dodge|Dodge]] brand in 1965 when Chrysler took a 60% stake in what was now Colmotores-Chrysler. GM took over Colmotores in 1979 (Chrysler was dropped from the company name at this point). Chevrolet truck production began in 1980. Chevrolet car production began in 1982. Colmotores became GM Colmotores in 1991. Closed in April 2024.&lt;ref&gt;{{Cite web|url=https://gmauthority.com/blog/2024/04/gm-shutting-down-manufacturing-operations-in-colombia-and-ecuador/|title = GM Shutting Down Manufacturing Operations In Colombia And Ecuador|author=Deivis Centeno|publisher=GMAuthority.com|date = April 29, 2024}}&lt;/ref&gt;&lt;ref&gt;{{Cite web|url=https://www.americaeconomia.com/en/business-industries/general-motors-announces-end-car-manufacturing-operations-colombia-and-ecuador/|title = General Motors announces the end of car manufacturing operations in Colombia and Ecuador|publisher=AmericaEconomia.com|date = April 26, 2024}}&lt;/ref&gt;

Past products from [[w:Chevrolet|Chevrolet]]: [[w:Chevrolet C/K#Third generation (1973–1991)|Chevrolet C-10]], [[w:Chevrolet C/K#Third generation (1973–1991)|Chevrolet C-30]], [[w:Chevrolet Celebrity|Chevrolet Celebrity]], [[w:Chevrolet Cruze#First generation (J300; 2008)|Chevrolet Cruze]], [[w:Chevrolet Kodiak|Chevrolet Kodiak]], [[w:GMC Brigadier|Chevrolet Brigadier/Super Brigadier]]&lt;br /&gt;Past products from [[w:GM do Brasil|GM do Brasil]]: [[w:Chevrolet Chevette#Latin America|Chevrolet Chevette]], [[w:Chevrolet Cobalt#Second generation (2011)|Chevrolet Cobalt]], [[w:Opel Ascona#Chevrolet Monza|Chevrolet Monza]]&lt;br /&gt;Past products from [[w:Isuzu|Isuzu]]: [[w:Isuzu Faster|Chevrolet LUV]], [[w:Isuzu Trooper#First generation (1981–1991)|Chevrolet Trooper]]&lt;br /&gt;Past products from [[w:Suzuki|Suzuki]]: [[w:Suzuki Cultus#First generation (1983)|Chevrolet Sprint]] (note: this is the same name as the one that was sold in the U.S. and Canada in the 80's), [[w:Suzuki Cultus#Second generation (1988)|Chevrolet Swift]], [[w:Suzuki Alto#Fifth generation (1998)|Chevrolet Alto]], [[w:Suzuki Cultus Crescent|Chevrolet Esteem]], [[w:Suzuki Jimny#Third generation (1998)|Chevrolet Jimny]], [[w:Suzuki Jimny#Second generation (1981)|Chevrolet Samurai]], [[w:Suzuki Solio#Predecessor: Wagon R-Wide (MA61S/MB61S; 1997)|Chevrolet Wagon R+]]&lt;br /&gt;Past products from [[w:Opel|Opel]]: [[w:Opel Corsa|Chevrolet Corsa]]&lt;br /&gt;Past products from [[w:GM Korea|Daewoo/GM Korea]]: [[w:Daewoo Matiz#Second generation (M200, M250; 2005)|Chevrolet Spark]], [[w:Daewoo Matiz#Third generation (M300; 2009)|Chevrolet Spark GT]], [[w:Daewoo Lacetti|Chevrolet Optra]], [[w:Daewoo Kalos|Chevrolet Aveo]]&lt;br /&gt;Products from [[w:SAIC-GM|SAIC-GM]]: [[w:Chevrolet Sail#Second generation (2010)|Chevrolet Sail]] 

|- 

|&amp;nbsp;||Constantine Transmission||[[w:Constantine, Michigan|Constantine, Michigan]]||United States||Automatic Transmissions||Between 1977 and 1980||Between 1987 and 1994|| Part of GM St. Joseph County Operations &amp; GM Hydramatic Division.

|- 

|&amp;nbsp;||Danville Foundry||[[w:Danville, Illinois|Danville, Illinois]]||United States||[[w:Casting|Iron castings]]||1943||1995|| Was part of GM's Central Foundry Division. Leased by [[w:Defense Plant Corporation|Defense Plant Corporation]] to pour castings for military equipment during [[w:World War II|World War II]]. Also supplied castings to Ford, Chrysler, and AMC. 

|- 

|&amp;nbsp;||Delco Chassis||[[w:Livonia, Michigan|Livonia, Michigan]]||United States||Bumpers||1953||1998||Site bought by GM in 1953. Located at 12950 and 13000 Eckles Road. Buildings demolished in 2001. Redeveloped into multi-tenant commercial use. One of the tenants is Amazon. 

|- 

|&amp;nbsp;||[[Delco Moraine NDH]] Dayton North (NDH=New Departure Hyatt)||[[w:Dayton, Ohio|Dayton, Ohio]] (Needmore Rd.)||United States||Master Cylinders/Brake Pads/Brake Calipers/ABS Assemblies||1965||1999||Located at 3100 Needmore Road. Spun off with [[w:Delphi Automotive|Delphi]] in 1999. Closed by Delphi in 2008. Demolished.  

|- 

|&amp;nbsp;||[[Delco Moraine NDH]] Dayton South (NDH=New Departure Hyatt)||[[w:Dayton, Ohio|Dayton, Ohio]] (Wisconsin Blvd.)||United States||Engine Bearings/Master Cylinders/Brake Pads/Brake Calipers/ABS Assemblies||1936||1999||Located at 1420 Wisconsin Boulevard. Delphi Chassis Systems. Spun off with [[w:Delphi Automotive|Delphi]] in 1999. Demolished in 2003.  

|- 

|&amp;nbsp;||[[Delco Moraine NDH]] (NDH=New Departure Hyatt)||[[w:Sandusky, Ohio|Sandusky, Ohio]]||United States||Wheel Bearings &amp; Wheel Bearing Assemblies||1946||1999||Located at 2509 Hayes Ave. Transferred to Delphi in 1995 which was then spun off in 1999, later sold to Hephaestus Holdings Inc. (HHI, Inc.), through its subsidiary Kyklos Bearing International (KBI) in 2008. HHI's parent, KPS Capital Partners, sold HHI to American Securities LLC in 2012. American Securities combined HHI with Metaldyne, which it also acquired in 2012, to form Metaldyne Performance Group (MPG) in 2014. Metaldyne closed the plant in 2017 when it exited the wheel bearing business.  

|- 

|&amp;nbsp;||[[Delco Products]]||[[w:Kettering, Ohio|Kettering, Ohio]]||United States||Shock Absorbers, Struts, Impact Absorbers, Electric Motors, Windshield Wiper Assemblies||1957||1999||Located at 2555 Woodman Dr. (Administrative offices were at 2000 Forrer Blvd.) Spun off with Delphi Automotive Systems in 1999. A large portion of the site has been used by [[w:Tenneco|Tenneco Inc.]] since 2008. 

|- 

|&amp;nbsp;||[[Delco Products Overseas Corp.]]||[[w:Dunstable|Dunstable]], [[w:Bedfordshire|Bedfordshire]], [[w:England|England]]||[[w:United Kingdom|United Kingdom]]||Windshield wiper motors, Wiper/washer units, Heater blower motors, Cooling fan motors, Ignition coils, Distributors, etc.||1934|| ?||Located on High Street North. In 1923, AC Sphinx Sparking Plug Co., Ltd. was created by a 50/50 merger of the British branch of AC Spark Plug Co. and the Sphinx Manufacturing Co., a British spark plug manufacturer based in Birmingham. When AC Spark Plug founder Albert Champion died in 1927, AC Sphinx became wholly owned by AC Spark Plug Co. of Flint, MI. GM was already the major shareholder in AC Spark Plug and took it over completely in 1933, including AC Sphinx in the UK. AC Sphinx Sparking Plug Co., Ltd. moved to Dunstable from their original site in Birmingham beginning in 1934. The transfer to Dunstable was completed in 1936 and the Birmingham plant was relinquished. Dunstable made spark plugs as well as many other automotive components. In 1946, GM Ltd. acquired AC Sphinx as well as Delco-Remy and Hyatt Ltd. from parent GM in the US. In 1947, AC Sphinx was renamed AC-Sphinx Plug Co., a division of GM Ltd. In 1952, AC-Sphinx Plug Co. was renamed AC-Delco division of GM Ltd. When the Southampton plant was added in 1952, production of automotive filters (air filters, fuel filters) was moved there from Dunstable. When the Kirkby plant was added in 1958, production of fuel pumps, thermostats, and instruments was moved there from Dunstable. In 1979, Dunstable became aligned with Delco Products in the US. In 1982, GM Ltd. was dissolved and Dunstable became Delco Products Overseas Corp., part of GM Overseas Corp.

|-

|&amp;nbsp;||[[w:Delco Remy|Delco Remy]]||[[w:Anaheim, California|Anaheim, California]]||United States||Batteries||1954||1999||Known as Plant 13. Located at 1201 N. Magnolia St. Supplied batteries to GM's California assembly plants like Fremont, Southgate and Van Nuys and to the West Coast aftermarket. Spun off with Delphi Automotive Systems in 1999. Closed by Delphi in 2005. Demolished. Is now Northgate Gonzalez Market. 

|- 

|&amp;nbsp;||[[w:Delco Remy|Delco Remy]]||[[w:Anderson, Indiana|Anderson, Indiana]]||United States||Starters, Generators, HEI Ignition, DIS Ignition, Switches, Magnets||1906||1994/1999|| The Heavy Duty Systems unit and a portion of the Automotive Systems unit (passenger car cranking motors) were spun off as [[w:Remy International|Delco Remy International]] in 1994, which was renamed [[w:Remy International|Remy International]] in 2004. Delco Remy International closed all manufacturing in Anderson in 2003. These parts of Delco Remy (the parts not spun off into Remy International) - Ignition (Plant 20) and Generator (Plant 11) products along with the Engineering Center (Plant 18) and Tooling (Plant 16) - merged with AC Rochester in 1994 to form AC Delco Systems. AC Delco Systems became part of GM's Delphi Automotive Systems subsidiary in 1995. Spun off with Delphi Automotive Systems in 1999. Delphi has since closed all 4 facilities in Anderson. Plant 11 closed in 2005 &amp; was demolished in 2006. Plant 16 (2316 Jefferson St.) was sold in 2011 ERTL Enterprises &amp; is now used by multiple businesses. Plant 18 (2900 South Scatterfield Road) closed in 2003 &amp; was turned over to the city Of Anderson in 2006. Plant 20 (2812 E 38th St.) closed in 2007 &amp; is now a distribution center for Sutong Tire Resources, a Chinese tire importer. Plant 45, at 6435 South Scatterfield Road, was the Magnequench plant that produced rare earth neodymium magnets. That business is now owned by NEO Material Technologies of Toronto, Ontario, Canada but the plant itself is now owned by Home Design Products, which makes plastic chairs and other products.

|- 

|&amp;nbsp;||[[w:Delco Remy|Delco Remy]]||[[w:Bloomfield, New Jersey|Bloomfield, New Jersey]]||United States||Batteries||1936||1945||Located on 55 La France Ave. During WWII, became part of GM's Eastern Aircraft Division from 1942 making wiring harnesses, hydraulic tubing and assemblies, and ammunition boxes for the Avenger bombers &amp; Wildcat fighters made by Eastern Aircraft. After WWII, it was replaced by the New Brunswick Battery Plant as it wasn't considered economically practical to convert back to battery production. Bloomfield produced 8 million batteries for Delco Remy. In 1950, the plant was sold to General Plastics for doing fluoropolymer coating.  General Plastics and the building still exist today.

|- 

|&amp;nbsp;||[[w:Delco Remy|Delco Remy]]||[[w:Fitzgerald, Georgia|Fitzgerald, Georgia]]||United States||Batteries||1973||1999||Known as Plant 22. Located at 342 Perry House Road. Supplied batteries to GM's Georgia assembly plants like Lakewood and Doraville and to the regional aftermarket. Spun off with Delphi Automotive Systems in 1999. Delphi sold its battery business to Johnson Controls in in July 2005 but the Fitzgerald plant continued supplying batteries to Johnson Controls through 2007. Closed by Delphi in 2007. Demolished. 

|-  

|&amp;nbsp;||[[w:Delco Remy|Delco Remy]]||[[w:Meridian, Mississippi|Meridian, Mississippi]]||United States||Starting motors, permanent magnet gear reduction cranking motors, powdered metal forge||1976||1994||Plant was originally built for National Homes Corp. Known as Plant 25. Spun off with [[w:Remy International|Delco Remy International]] in 1994. Closed by Delco Remy International in 1998. Production consolidated in Anderson, Indiana.

|-

|&amp;nbsp;||[[w:Delco Remy|Delco Remy]]/&lt;br&gt;[[w:Sheridan (automobile)|Sheridan]]||[[w:Muncie, Indiana|Muncie, Indiana]]||United States||Sheridan automobiles &lt;br&gt;Batteries||1919&lt;br&gt;1928||1921&lt;br&gt;1978||Located on West Willard Street. Originally built in 1908 by [[w:Inter-State Automobile Company|Inter-State Automobile Company]] which went bankrupt in 1913 and was renamed Inter-State Motor Company, resuming production in 1914. Built tractors for the military in WWI but did not resume civilian production in 1918 and the factory was idled. GM owned the plant from 1919-1921 to build the [[w:Sheridan (automobile)|Sheridan]] brand. Sold to [[w:Durant Motors|Durant Motors]] in 1921. Bought by Delco Remy division of GM in 1928. Known as Plant 9. Replaced by more modern Plant 26 in 1978. Plant 9 was demolished in 1978-79. 

|- 


|&amp;nbsp;||[[w:Delco Remy|Delco Remy]]||[[w:Muncie, Indiana|Muncie, Indiana]]||United States||Batteries||1977||1994|| Located at 4500 S.  Delaware Dr. Known as Plant 26. Replaced Plant 9 in 1978. Plant 26 closed and was demolished in 1998.  

|- 

|&amp;nbsp;||[[w:Delco Remy|Delco Remy]]||[[w:New Brunswick, New Jersey|New Brunswick, New Jersey]]||United States||Batteries||1946||1999||Known as Plant 12. Located at 167 Jersey Ave. Replaced the pre-war Bloomfield plant. Supplied batteries to GM's East Coast assembly plants like Tarrytown, Wilmington, and Baltimore and to the East Coast aftermarket. Started making Freedom batteries in 1973 for Chevy Vega. Spun off with Delphi Automotive Systems in 1999. Delphi sold to Johnson Controls in August 2006. Closed by Johnson Controls in 2007. Partly demolished in 2014 (the south half of the building along with the guard shack in front of the plant). The remaining facility at the north end of the property is now the Cal-Chlor Corp. East Packaging and Distribution Facility. The former south end of the plant is now used for storage by Cal-Chlor.

|-  

|&amp;nbsp;||[[w:Delco Remy|Delco Remy]]||[[w:Olathe, Kansas|Olathe, Kansas]]||United States||Batteries||1956||1999||Known as Plant 14. Located at 400 W. Dennis Ave. Supplied batteries to GM's Midwest assembly plants like Fairfax, Oklahoma City and Wentzville. Olathe was the first plant to produce the maintenance-free battery in 1970-1971 employing what was described as wire wound grid technology. The product was sold exclusively to JC Penny. Spun off with Delphi Automotive Systems in 1999. Last product produced was a heavy duty battery for Caterpillar. Closed by Delphi in 2005. Demolished. Site being redeveloped as Olathe Commerce Park. Some of the site is now a Jett Trucking terminal.

|-

|9 (1979-1988)&lt;br /&gt;&lt;br /&gt; Q&amp;nbsp;(1971-1978)||[[w:Detroit Assembly|Detroit Assembly]] (Cadillac Clark Street plant)||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||[[w:Cadillac|Cadillac]]s including &lt;br&gt;  [[w:Cadillac Series 62|Cadillac Series 62]] (1940-1942, 1946-1964),&lt;br&gt; [[w:Cadillac Calais|Cadillac Calais]] (1965-1976), &lt;br&gt; [[w:Cadillac DeVille|Cadillac DeVille]] (1949-1984),&lt;br&gt; [[w:Cadillac Sixty Special|Cadillac Sixty Special]] (1938-1942, 1946-1976),&lt;br&gt; [[w:Cadillac Fleetwood Brougham|Cadillac Fleetwood Brougham]] (1977-1986),&lt;br&gt; [[w:Cadillac Brougham|Cadillac Brougham]] (1987-1988),&lt;br&gt; [[w:Cadillac Eldorado|Cadillac Eldorado]] (1953-1978),&lt;br&gt; [[w:Cadillac Eldorado#1957–1958 Eldorado Brougham|Cadillac Eldorado Brougham (Series 70)]] (1957-1958),&lt;br&gt; [[w:Cadillac Eldorado#1959–60 Eldorado Brougham|Cadillac Eldorado Brougham (Series 6900)]] (1959-1960) (chassis &amp; final finishing),&lt;br&gt; [[w:Cadillac Seville#First generation (1976–1979)|Cadillac Seville]] (1976-1979), &lt;br /&gt;[[w:LaSalle (automobile)|LaSalle]] (1934-1940)&lt;br /&gt;[[w:Chevrolet Caprice#Third generation (1977–1990)|Chevrolet Caprice]] (1986-1987)&lt;br /&gt;[[w:Oldsmobile Custom Cruiser#Second generation (1977–1990)|Oldsmobile Custom Cruiser]] (1985-1987)&lt;br /&gt;[[w:Oldsmobile 88#Eighth generation (1977–1985)|Oldsmobile Delta 88]] (1984-1985) &lt;br /&gt;Cadillac engines (V8, V12, V16) &lt;br /&gt; LaSalle straight-8 (1934-1936) (based on Oldsmobile straight-8 but assembled by Cadillac from Oldsmobile supplied components)||1921||1987||Located at 2860 Clark St. This was Cadillac's home plant and built all Cadillacs until 1971. During WWII, it built M5 &amp; M5A1 Stuart tanks and M24 Chaffee tanks. Cadillac also built the V8 engines that powered these tanks &amp; it also supplied engines to power these tank models made by other GM divisions and other companies as well as to power other types of armored vehicles. Cadillac also made components for aircraft engines made by GM's Allison Division. Cadillac also made M8 75mm howitzer motor carriages &amp; M19 Twin 40mm anti-aircraft carriages. Factory closed December 1987. Chrome plating operation closed in March 1993. Engineering building (including tool room) closed in March 1994. Demolished entirely. Redeveloped into Clark Street Technology Park in 1997. 

|- 

|&amp;nbsp;||[[w:Fleetwood Metal Body#Purchase by Fisher|Fleetwood - Detroit Body Assembly]] (Fisher Body No. 18)||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||Bodies for [[w:Cadillac|Cadillac]] &amp; [[w:LaSalle (automobile)|LaSalle]]||1917||1987||Originally built to build aircraft for World War I. Taken over by Fisher Body in 1919 &amp; given to Fleetwood Metal Body after Fisher Body took over Fleetwood in 1925. Fleetwood Metal Body plant. Also known as Fisher Body Plant #18. Supplied bodies to Cadillac's Clark St. plant in Detroit. Located at 261 West End Ave in the [[w:Delray, Detroit|Delray]] neighborhood of Detroit. Redeveloped into Container Port Group's Detroit facility. 

|-  

|&amp;nbsp;||[[w:Detroit Diesel|Detroit Diesel]]||[[w:Redford, Michigan|Redford, Michigan]]||United States||Diesel engines for commercial vehicles||1938||1994||Located at 13400 W. Outer Drive. Was the Detroit Diesel-Allison Division from 1970 through 1987 when it again became the the Detroit Diesel Division. Spun off in 1988 as the Detroit Diesel Corp., a joint venture with Penske Corp., which had a majority stake of 60%. Penske increased its stake to 80% later in 1988 and then to 100% in 1994. Penske sold Detroit Diesel to DaimlerChrysler in 2000. DaimlerChrysler became Daimler AG in 2007. In 2019, Daimler AG spun off its truck and bus operations including Detroit Diesel into a separate company called Daimler Truck Holding AG.

|-

|&amp;nbsp;||Detroit Forge||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||Forged metal components||c.1919||1994||Located at 8435 St Aubin St.  Straddles the border of [[w:Detroit|Detroit]] and [[w:Hamtramck|Hamtramck]]. Sold to [[w:American Axle|American Axle]] &amp; Manufacturing Inc. in 1994. Closed in 2008, subsequently demolished around 2014.  

|- 

|3||Chevrolet-Detroit Truck &amp; Bus Plant||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||[[w:Chevrolet Step-Van|Chevrolet Step-Van]]&lt;br /&gt;[[w:Chevrolet Step-Van|GMC Value-Van]]&lt;br /&gt;Chevrolet &amp; GMC P-Series motorhome &amp; commercial chassis&lt;br /&gt;[[w:Chevrolet van#1992–1996|Chevrolet Van G30 HD/ GMC Vandura G3500 HD cutaway]] (Based on P-series P30 chassis with extended front end &amp;  forward-tilting hood) 1993-1996||1974||1999||Located at 601 Piquette Ave. in Detroit (Formerly Fisher Body No. 23). P-Series motorhome &amp; stepvan chassis business (Commercial and Motorhome Chassis Division) was sold to investors (not including the Detroit plant) and became Workhorse Custom Chassis in 1999. Workhorse was later acquired by Navistar International in 2005, which later closed the Workhorse business in 2012 and sold the assets to AMP Electric Vehicles in 2013.  

|- 

|&amp;nbsp;||Detroit Transmission Division - Detroit||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||[[w:Hydramatic|Hydramatic]] automatic transmissions||1939||1949||Was located at 5140 Riopelle St. (between Farnsworth St. &amp; Theodore St.) in what had been Fisher Body Plant #10. Original assembly site for the world's first production, fully automatic transmission and the headquarters of the new GM division created to produce it - the Detroit Transmission Division. First production Hydramatic shipped to Oldsmobile in October 1939. Debuted on the 1940 Oldsmobile. A heavier-duty version then launched on the 1941 Cadillac. Hydramatics continued to be produced during World War II for use in M5/M5A1 Stuart and M24 Chafee tanks (mated to Cadillac V8s), T17E1 Staghound and  T18E2 Boarhound armored cars (mated to GMC inline-6's), M8 75mm howitzer motor carriages (mated to Cadillac V8s), LVT-3 Bushmaster amphibious landing vehicles (mated to Cadillac V8s), &amp; Mark 1 Armored Snowmobiles made by Bombardier of Canada (mated to a Cadillac V8). Hydramatic became optional on Pontiacs in 1948. Hydramatic also became optional on Lincolns in 1949. The 1 millionth Hydramatic was built in January 1949. Needing more production capacity than the original factory in Detroit could handle, the Detroit Transmission Division relocated to a newer and much bigger plant in Livonia, Michigan in September 1949. Was later used by Cadillac as a parts warehouse supplying its Clark St. plant in Detroit. Closed by GM in the early 1980's and sold. Was subsequently used by Total Foods. Last occupied by Palmer Promotional Products. Heavily damaged by a fire in February 2014. The remains of the building were then demolished by summer 2014. 

|- 

|&amp;nbsp;||Detroit Transmission Division - Livonia||[[w:Livonia, Michigan|Livonia]], [[w:Michigan|Michigan]]||United States||[[w:Hydramatic|Hydramatic]] automatic transmissions||1949||1953||The Detroit Transmission Division moved from Detroit to a newer and larger factory in Livonia in 1949. In addition to Pontiac, Oldsmobile, &amp; Cadillac, Livonia also supplied Hydramatics to Lincoln, Nash, Hudson, Kaiser, and Fraser. However, the factory burned down in August 1953 causing 6 deaths and more than $80 million in damage. GM quickly arranged to lease Kaiser’s Willow Run factory to replace the destroyed Livonia plant and GM then bought the plant outright in November 1953 for $26 million. Salvaged equipment from Livonia was taken to [[w:Willow Run#General Motors operations|Willow Run]]; see [[w:Willow Run Transmission|Willow Run Transmission]]. 

|- 

|5&lt;br /&gt;&lt;br /&gt;C (1962-1978)||[[w:General Motors Diesel|General Motors Diesel]]||[[w:London, Ontario|London, Ontario]]||[[w:Canada|Canada]]||[[w:List of GM-EMD locomotives|EMD Locomotives]]&lt;br /&gt;[[w:GM New Look (Fishbowl) Bus|GM New Look bus]] (1961-1978)&lt;br /&gt;Terex earthmovers (1965-1980)&lt;br /&gt;Military vehicles including:&lt;br /&gt;[[w:AVGP|Grizzly/Cougar/Husky LAV I]]&lt;br /&gt;[[w:LAV II|LAV II (LAV-25/Bison/Coyote)]]&lt;br /&gt;[[w:LAV III|LAV III]]&lt;br /&gt;[[w:Stryker|Stryker]]||1950 (GM Electro-Motive Division)&lt;br /&gt;&lt;br /&gt;1961 (Transit bus)||1979 (Transit bus)&lt;br /&gt;&lt;br /&gt;2003 (GM Defense)&lt;br /&gt;&lt;br /&gt;2005 (GM Electro-Motive Division)||Transit bus production began in London, Ontario in late 1961. Transit bus production moved to Saint-Eustache factory in 1979. The part of the property making military vehicles (armored fighting vehicles like the [[w:Stryker|Stryker]]) as GM Defense was sold in 2003 to [[w:General Dynamics Land Systems|General Dynamics Land Systems]], becoming [[w:General Dynamics Land Systems#General Dynamics Land Systems Canada|General Dynamics Land Systems – Canada (GDLS-C)]]. Located at 1991 Oxford St E. Interestingly, General Dynamics Land Systems was originally formed in 1982 when General Dynamics bought Chrysler Defense, Chrysler's tank division in the US, which was then renamed General Dynamics Land Systems. The locomotive operations were sold in 2005 and renamed [[w:Electro-Motive Diesel|Electro-Motive Diesel]], Inc. Electro-Motive was then sold to [[w:Caterpillar Inc.|Caterpillar's]] [[w:Progress Rail|Progress Rail]] subsidiary in 2010. The London, ON plant was then shuttered in 2012 &amp; operations moved to a new plant in Muncie, Indiana. This part of the plant is now used by HCL Logistics, which provides logistics services to next door General Dynamics Land Systems – Canada. Located at 2021 Oxford St. E.  

|- 

|3 (1981-1987)&lt;br /&gt;&lt;br /&gt;M (1979-1980)||[[w:General Motors Diesel|General Motors Diesel]] Saint-Eustache Bus Plant||[[w:Saint-Eustache, Quebec|Saint-Eustache, Quebec]]||[[w:Canada|Canada]]||[[w:GM New Look (Fishbowl) Bus|GM New Look bus]] (1979-1986)&lt;br /&gt;[[w:Classic (transit bus)|GM Classic bus]] (1983-1987)||1979||1987||Located at 1000 Industriel Blvd. Manufactures [[w:transit bus|transit bus]]es. GM consolidated Canadian transit bus production here from the London, Ontario and St. Laurent, Quebec plants in 1979. New Look transit bus production ended in 1986. Sold to [[w:Motor Coach Industries|Motor Coach Industries]], along with the designs for the [[w:Classic (transit bus)|Classic]] bus models this factory still produced in 1987. Later sold to [[w:Nova Bus|Nova Bus]] in 1993. Production of the Classic model bus ended in 1997. Still owned by [[w:Nova Bus|Nova Bus]], which is owned by [[w:Volvo AB|Volvo AB]] through [[w:Prevost (bus manufacturer)|Prevost Car]]. Prevost bought 51% of Nova Bus in 1998 and bought the remaining 49% from Henlys Group in 2004. 

|- 

|M|| [[w:General Motors Diesel|General Motors Diesel]] Saint Laurent Bus Plant || [[w:Saint Laurent, Quebec|Saint Laurent, Quebec]] || Canada || [[w:GM New Look bus|GM New Look bus]] (1975-1979)

|| 1974 || 1979 || Bus operations moved to [[w:Saint-Eustache, Quebec|Saint-Eustache, Quebec]]. 

|- 

|D &lt;br /&gt;(1960-1964 [[w:Pontiac (automobile)|Pontiac]] and 1965-2009)&lt;br /&gt;&lt;br /&gt; C (1964 [[w:Chevrolet|Chevrolet]])&lt;br /&gt;&lt;br /&gt;A (Pre-1965 [[w:Oldsmobile|Oldsmobile]] and Pre-1960 [[w:Pontiac (automobile)|Pontiac]])&lt;br /&gt;&lt;br /&gt;6 (Pre-1964 [[w:Buick|Buick]])||[[w:Doraville Assembly|Doraville Assembly]]||[[w:Doraville, Georgia|Doraville, Georgia]]||United States||[[w:Chevrolet Uplander|Chevrolet Uplander]] (2005-2008 &amp; '09 in Canada)&lt;br /&gt;[[w:Pontiac Montana#Second generation (2005)|Pontiac Montana SV6]] (2005-2006 &amp; '07-'09 in Canada)&lt;br /&gt;[[w:Buick Terraza|Buick Terraza]] (2005-2007)&lt;br /&gt;[[w:Saturn Relay|Saturn Relay]] (2005-2007)||1947||2008||Located at 3900 Motors Industrial Way. Was originally part of the [[w:Buick-Oldsmobile-Pontiac Assembly Division|Buick-Oldsmobile-Pontiac Assembly Division]]. First vehicle built in Nov. 1947 was an Oldsmobile. Some of the original property bought by GM for the Doraville plant in 1945 was deemed as excess and was sold off. One of the parts that was sold (82 acres) was sold to Chevrolet to build a parts warehouse. Doraville began making Chevrolet passenger cars for 1964. BOP Assembly Division became GM Assembly Division in 1965. Oldsmobile and Pontiac production ended in Dec. 1965, leaving just Chevrolet and Buick. Oldsmobile production resumed in Aug. 1967 for the 1968 model year. Oldsmobile production again ended in April 1970 followed by Buick production in July 1970. Pontiac production resumed in Aug. 1970 for the 1971 model year. B-body full-size Chevrolet and Pontiac production ended in Dec. 1973 and midsize A-body Chevrolet and Oldsmobile production began in Jan. 1974.[https://dekalbhistory.org/wp-content/uploads/2020/04/history-of-doraville-gm-plant.pdf] Doraville switched to building fwd A-body Oldsmobiles and Buicks for 1982. Doraville then switched to building W-body Oldsmobiles for 1988. Passenger car production ended in 1995 and the Cutlass Supreme coupe &amp; sedan were moved to Fairfax II during 1995 while the convertible was discontinued. Doraville was converted to build minivans for 1997. Production ended in September 2008. Last vehicle built was a Chevy Uplander. Demolished in 2014-2015. Site is being redeveloped. Parts of the site are now occupied by Nalley Automotive Group (Infiniti dealership &amp; a Collision Center), Mike Rezi Nissan (formerly Nalley Nissan), Assembly Studios Atlanta, Third Rail Studios at Assembly Atlanta, and Serta Simmons Bedding.&lt;br /&gt;Past models: [[w:Chevrolet Venture|Chevrolet Venture]] (1997-2005), [[w:Oldsmobile Silhouette#Second generation (1997–2004)|Oldsmobile Silhouette]] (1997-2004), [[w:Pontiac Trans Sport#Second generation (1997-1999)|Pontiac Trans Sport]] (1997-1998), [[w:Pontiac Montana|Pontiac Montana]] (1999-2005), [[w:Pontiac Trans Sport#Second generation (Chevrolet)|Chevrolet Trans Sport]] (Europe: '97-'04), [[w:Buick Century#Second generation (1954–1958)|Buick Century]] (1954-1958), [[w:Buick Century#Fifth generation (1982–1996)|Buick Century]] (1982-1987), [[w:Buick Electra|Buick Electra]] (1959-1962), [[w:Buick Invicta|Buick Invicta]] (1959-1962), [[w:Buick LeSabre|Buick Lesabre]] (1959-1970), [[w:Buick Roadmaster|Buick Roadmaster]] (1951-1952, 1954-1958), [[w:Buick Special|Buick Special]] (1950-1958), [[w:Buick Super|Buick Super]] (1955, 1957-1958), [[w:Buick Wildcat|Buick Wildcat]] (1963, 1965-1970), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1964-1970), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1964-70), [[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-74), [[w:Chevrolet Chevelle#Third generation (1973–1977)|Chevrolet Chevelle]] (1974-77), [[w:Chevrolet Impala|Chevrolet Impala]] (1964-1974), [[w:Chevrolet Malibu#Fourth generation (1978)|Chevrolet Malibu]] (1978-1981), [[w:Chevrolet Monte Carlo|Chevrolet Monte Carlo]] (1975-1980), [[w:Oldsmobile Cutlass#Fourth generation (intermediate) 1973–1977|Oldsmobile Cutlass]] (Gen 4) (1974-1977), [[w:Oldsmobile Cutlass#Fifth-generation (intermediate) 1978–1988|Oldsmobile Cutlass]] (Gen 5) (1978-1981), [[w:Oldsmobile Cutlass Ciera|Oldsmobile Cutlass Ciera]] (1982-1987), [[w:Oldsmobile Cutlass Supreme#Fifth generation (1988–1997)|Oldsmobile Cutlass Supreme]] (1988-1995), [[w:Oldsmobile 88|Oldsmobile 88]] (1949-1966, 1968-1970), [[w:Oldsmobile 98|Oldsmobile 98]] (1948-1963), [[w:Oldsmobile Starfire#First generation (1961–1966)|Oldsmobile Starfire]] (1961-1966), [[w:Pontiac 2+2|Pontiac 2+2]] (1964-1966),  [[w:Pontiac Bonneville|Pontiac Bonneville]] (1958, 1960-1966), [[w:Pontiac Grand Prix#First generation (1962–1964)|Pontiac Grand Prix]] (1962-1964), [[w:Pontiac Catalina|Pontiac Catalina]] (1960-1966, 1971-1974), [[w:Pontiac Chieftain|Pontiac Chieftain]] (1951, 1953, 1955, 1958), [[w:Pontiac Grand Ville|Pontiac Grand Ville]] (1973-1974), [[w:Pontiac Star Chief|Pontiac Star Chief]] (1955-1958, 1964), [[w:Pontiac Ventura#1960–1970|Pontiac Ventura]] (1961),&lt;br&gt; [[w:Chevrolet El Camino|Chevrolet El Camino]] (1974-1981), [[w:GMC Sprint |GMC Sprint]] (1974-77), [[w:GMC Caballero|GMC Caballero]] (1978-1981),&lt;br&gt;  [[w:Opel Sintra|Opel Sintra]]/[[w:Vauxhall Sintra|Vauxhall Sintra]] (1997-1999). 

|- 

|&amp;nbsp;||General Motors East Africa||[[w:Nairobi|Nairobi]]||[[w:Kenya|Kenya]]||[[w:Isuzu F-Series|Isuzu F-Series]]&lt;br /&gt;[[w:Isuzu N-Series|Isuzu N-Series]]&lt;br /&gt;Isuzu buses&lt;br /&gt;&lt;br /&gt;||1977||2017||Originally established in 1975 as GM Kenya, a joint venture with the Kenyan govt. Renamed GM East Africa in 2003. Other shareholders are Kenya’s Industrial and Commercial Development Corporation (ICDC): 20%, Centum Investment Co. Ltd.: 17.8%, &amp; Itochu Corporation: 4.5%. 

Isuzu moved pickup production to South Africa in 2012 so it could focus on trucks &amp; buses at the Nairobi plant. &lt;br /&gt; 

GM sold its 57.7% stake in the factory to Isuzu in 2017 and left the Kenyan market. Now known as Isuzu East Africa. &lt;br /&gt; 

Past models: [[w:Isuzu D-Max|Isuzu D-Max]], [[w:Bedford Vehicles|Bedford trucks]], [[w:Bedford HA#The BTV|BTV]] 

|- 

|&amp;nbsp;||ELAZ-GM||[[w:Yelabuga|Yelabuga]], [[w:Tatarstan|Tatarstan]]||[[w:Russia|Russia]]||[[w:Chevrolet S-10 Blazer#Second generation (1995)|Chevrolet Blazer]]||1996||2001||GM owned about 25% &amp; ELAZ owned the other 75%. Joint venture dissolved in 2001.  

|- 

|&amp;nbsp;||[[w:Electro Motive Division|Electro Motive Division]] - [[w:Electro-Motive Diesel#EMD La Grange (McCook)|La Grange Operations]]||[[w:McCook, Illinois|McCook, Illinois]]||United States||[[w:List of GM-EMD locomotives|Locomotives]]&lt;br /&gt;Engines&lt;br /&gt;Components||1936|| ||Located at 9301 W. 55th St.&lt;br /&gt; Electro-Motive headquarters and R&amp;D operations. Locomotive production ended in 1991 and was moved to London, ON, Canada. Sold in 2005, renamed [[w:Electro-Motive Diesel|Electro-Motive Diesel]], bought by Caterpillar's Progress Rail subsidiary in 2010.  

|-

|&amp;nbsp;||[[w:Elmore Manufacturing Company|Elmore]]||[[w:Clyde, Ohio|Clyde]], [[w:Ohio|Ohio]]||United States||Elmore automobiles||1909||1912|| Factory was located on Amanda St. Bought by GM in November 1909. Elmore was known for its two-stroke engines. GM closed it down in the fall of 1912. GM sold the factory to a truckmaker named Krebs Commercial Car Company in 1912. In 1917, Krebs Commercial Car Company merged with Clyde Cars Company and Lincoln Motor Truck Company to form what became Clydesdale Motor Truck Company in 1919. Clydesdale Motor Truck Company closed in 1939 and the factory was then used by Clyde Porcelain Steel Company until the factory burned down November 11, 1945. The factory would be rebuilt and used for making washing machines by various companies, most recently, Whirlpool Corp.

|- 

|&amp;nbsp;||Ewing||[[w:Geneva, Ohio|Geneva]], [[w:Ohio|Ohio]]||United States||Ewing automobiles||1909||1911||Bought by GM in October 1909. Made taxis. GM closed it down in 1911.

|-

|X (1965–1987)&lt;br /&gt;&lt;br /&gt;K (Pre-1965 [[w:Oldsmobile|Oldsmobile]] &amp; [[w:Pontiac (automobile)|Pontiac]])&lt;br /&gt;&lt;br /&gt;4 (Pre-1965 [[w:Buick|Buick]])||[[w:Fairfax Assembly|Fairfax Assembly]] (Fairfax I)||[[w:Kansas City, Kansas|Kansas City, Kansas]]||United States||[[w:Buick Centurion|Buick Centurion]] (1971-1973), [[w:Buick Century#Second generation (1954–1958)|Buick Century]] (1954-1958), [[w:Buick Electra|Buick Electra]] (1959-1963, 1971-1974), [[w:Buick Estate|Buick Estate]] (1970-1979), [[w:Buick Estate#1977–1990|Buick Electra Estate]] (1980-1987), [[w:Buick Invicta|Buick Invicta]] (1959-1962), [[w:Buick LeSabre|Buick LeSabre]] (1959-1985), [[w:Buick Estate#1977–1990|Buick LeSabre Estate]] (1980-1987), [[w:Buick Limited|Buick Limited]] (1958), [[w:Buick Roadmaster|Buick Roadmaster]] (1948-1949, 1951, 1953, 1956-1958), [[w:Buick Skylark#First generation (1961–1963)|Buick Skylark]] (1962-1963), [[w:Buick Special|Buick Special (B-body)]] (1947-1950, 1952-1958), [[w:Buick Special#1961–1963|Buick Special (Y-body)]] (1962-1963), [[w:Buick Super|Buick Super]] (1954-1958), [[w:Buick Wildcat|Buick Wildcat]] (1963-1970), [[w:Chevrolet Caprice|Chevrolet Caprice]] (1982-1987), [[w:Chevrolet Impala|Chevrolet Impala]] (1982-1985), [[w:Oldsmobile 88|Oldsmobile 88]] (1949-1984), [[w:Oldsmobile 98|Oldsmobile 98]] (1948-1963), [[w:Oldsmobile F-85|Oldsmobile F-85/&lt;br&gt;Cutlass]] (1962-1963), [[w:Oldsmobile Custom Cruiser|Oldsmobile Custom Cruiser]] (1974-1984), [[w:Oldsmobile Jetstar I|Oldsmobile Jetstar I]] (1964-1965), [[w:Oldsmobile Starfire#First generation (1961–1966)|Oldsmobile Starfire]] (1961-1966), [[w:Pontiac 2+2|Pontiac 2+2]] (1964-1967), [[w:Pontiac Bonneville#Sixth generation (1977–1981)|Pontiac Bonneville]] (1958-70, 1975-1981), [[w:Pontiac Catalina|Pontiac Catalina]] (1959-1981), [[w:Pontiac Chieftain|Pontiac Chieftain]] (1950-1958), [[w:Pontiac Executive|Pontiac Executive]] (1967-1968), [[w:Pontiac Grand Prix|Pontiac Grand Prix]] (1962-1968), [[w:Pontiac Grand Ville|Pontiac Grand Ville]] (1971-1975), [[w:Pontiac LeMans#First generation (1961–1963)|Pontiac LeMans]] (1962-1963), [[w:Pontiac Parisienne#Fifth generation: 1977–1986|Pontiac Parisienne]] (1984-1986), [[w:Pontiac Safari|Pontiac Safari]] (1987), [[w:Pontiac Star Chief|Pontiac Star Chief]] (1954-1959, 1964, 1966), [[w:Pontiac Tempest#First generation (1961–1963)|Pontiac Tempest]] (1962-1963), [[w:Pontiac Ventura#1960–1970|Pontiac Ventura]] (1960-1961) ||1946||1987||Located at 100 Kindelberger Road. Originally, the location of the [[w:North American Aviation|North American Aviation]] Bomber Production Plant (built in 1940) where the [[w:B-25 Mitchell|B-25 Mitchell]] was manufactured during World War II. After the war, GM leased it in 1945 and converted the plant to auto production. Automotive production began in June 1946. GM later bought the plant in 1960. Was originally part of the [[w:Buick-Oldsmobile-Pontiac Assembly Division|Buick-Oldsmobile-Pontiac Assembly Division]]. BOP Assembly Division became GM Assembly Division in 1965. Fairfax mostly focused on full-size cars ([[w:General Motors A platform (RWD)#1926-1959|A-]], B-, &amp; C-body) but it also built B-O-P Y-body compact cars for 1962-1963. Fairfax only began making Chevrolet passenger cars for 1982. Also built [[w:F-84F Thunderstreak|F-84F Thunderstreak]] fighter jets alongside cars beginning in 1952 and ending in May 1955 when the contract ended. Plant closed May 1987. Production moved to new building on adjacent site (Fairfax II) for 1988 model year production. 

|- 

|&amp;nbsp;||[[w:History of General Motors#Corporate restructuring and operating losses|Fiat-GM Powertrain Polska]]||[[w:Bielsko-Biala|Bielsko-Biala]]||[[w:Poland|Poland]]||[[w:Fiat JTD engine#1.3 JTDm/Multijet/CDTI/D/DDiS/HDi|GM Small Diesel Engine]] ||2003||2010|| Engine began production here in 2003 as part of Fiat-GM Powertrain, a 50/50 joint venture between GM &amp; Fiat involving joint development and production of engines and transmissions. The joint venture was disbanded in 2005. As part of the dissolution, GM took a 50% stake in the Bielsko-Biala engine plant and the intellectual property of the 1.3 liter diesel engine produced there. In 2010, GM sold its half of the Bielsko-Biala engine plant back to Fiat. However, GM kept its half of the intellectual property of the 1.3 liter diesel engine produced there and continued to source the 1.3 liter diesel engine from the Bielsko-Biala engine plant. Chevrolet stopped using this engine around 2015. Opel was still using this engine when it was sold by GM to PSA in 2017. Opel last used this engine in 2019. This plant became part of [[w:Fiat Chrysler Automobiles|FCA]] in 2014 when Fiat and Chrysler Group merged. This plant became part of [[w:Stellantis|Stellantis]] in 2021 when FCA merged with PSA Group. Stellantis has announced that the Bielsko-Biala engine plant will close by the end of 2024.   

|- 

|&amp;nbsp;||Fisher Body No. 10||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||Auto bodies ||1917-&lt;br /&gt;1919||1939||Was located at 5140 Riopelle St. (between Farnsworth St. &amp; Theodore St.).GM bought 60% of Fisher Body in 1919 and bought the remainder in 1926. From 1926, Fisher Body only supplied bodies to GM brands. In 1939, became headquarters and manufacturing site of GM's new Detroit Transmission Division, which manufactured Hydramatic fully automatic transmissions that first appeared on the 1940 Oldsmobile.
|- 

|&amp;nbsp;||[[w:Fisher Body#Fisher Body Corporation and General Motors|Fisher Body No. 12]]||[[w:Detroit|Detroit]], Michigan||United States|| ||1916||1942||Located at 1961 E. Milwaukee Ave. Previously used by Metzger Motor Car Company from 1910-1913 and [[w:Maxwell Motor Company|Maxwell Motor Company]] from 1913-1916. Owned by Fisher from 1916-1942 then sold to J. Lee Hackett Co. which owned it until 1973. Used for warehousing from 1973-1981 and then demolished.  

|- 

|&amp;nbsp;||[[w:Fisher Body#Fisher Body Corporation and General Motors|Fisher Body No. 21]]||[[w:Detroit|Detroit]], Michigan||United States||Bodies for Buick &amp; Cadillac&lt;br /&gt;Engineering and Tool &amp; Die operations&lt;br /&gt;Bodies for Cadillac limousines&lt;br /&gt;Pre-production Pilot bodies||1919||1984||Located at 700 Piquette Ave. In 1999, was re-addressed as 6051 Hastings Street. Made bodies for Buick through 1926 when Buick body production moved to Fisher Body Plant No. 1 - Flint on S. Saginaw St. Made bodies for Cadillac through 1929 when Cadillac body production moved to the Fisher Body Plant No. 18/Fleetwood Body plant. Became an engineering facility from 1930-1955. Produced parts for B-25 &amp; B-29 bombers in World War II (Aircraft Unit). Also did product development and engineering during World War II (Central Development and Experimental Unit). In 1955, GM transferred production of Cadillac limousine bodies from the Fleetwood plant in Detroit to Fisher #21 plant due to it being a low-volume operation. Closed April 1984. Sold to Cameo Color Coat in 1985 which transferred it to Carter Color Coat in 1990. Carter Color Coat then went bankrupt and the property was abandoned in 1993. GM removed some paints and other hazardous materials in the early 1990s. It's been owned by the city of Detroit since 2000. Now being converted into Fisher 21 Lofts, a mixed residential and commercial development scheduled to open in 2027.

|- 

|&amp;nbsp;||[[w:Fisher Body#Fisher Body Corporation and General Motors|Fisher Body No. 23/23B]]||[[w:Detroit|Detroit]], Michigan||United States||Tool &amp; Die plant through 1972.||1921||1972||Located at 601 Piquette Ave. #23 was the six story portion while #23B was the one story portion. Known as the Detroit Die and Machine Plant. In WWII, made B-25, B-29, P-80 aircraft tools and fixtures; M4, M10, M36, M26, M18 tank parts; 3-inch and 5-inch Naval Gun Breech Housings, 155mm and 8-in. gun parts, Diesel Engine parts and Torqmatic Transmission parts. Became Chevrolet's Detroit Truck &amp; Bus plant in 1974. 

|- 

|&amp;nbsp;||[[w:Fisher Body#Fisher Body Corporation and General Motors|Fisher Body No. 37]]||[[w:Detroit|Detroit]], Michigan||United States||Large bodyside stampings||1919||1985||Located at 950 E Milwaukee Ave. Produced aircraft and tank assemblies, 90 mm AA guns, 5” naval gun housings and Lockheed missile parts during World War II. In 1989, bought by Lakeside Stamping which was renamed New Center Stamping in 1994. In 2019, New Center Stamping Inc. was taken over by Soave Enterprises and still stamps parts for automakers including GM, Ford, and Stellantis. 

|- 

|&amp;nbsp;||Fisher Body No. 40||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||Tooling ||1928||1983-1984||Was located at 1500 E. Ferry St. Plant 41 was next door and was used for storage. 

|-

|&amp;nbsp;||Fisher Body Overseas Corp. - Dundonald plant||[[w:Dundonald, County Down|Dundonald]], [[w:Northern Ireland|Northern Ireland]]||[[w:United Kingdom|United Kingdom]] ||Seat Belts, window regulators, door locks, door switches, &amp; other automotive hardware||1980||1988||Located at 770 Upper Newtownards Road at the corner of Carrowreagh Road. Dundonald is an eastern suburb of Belfast. From 1966-1977, was a Rolls-Royce plant making aircraft engine parts. GM's Fisher Body division bought the plant in 1978 and reopened it in 1979. Production began in 1980. In 1982, the Dundonald plant became part of Fisher Body Overseas Corp., part of GM Overseas Corp. Sold to Takata Corp. in 1988. Operated as European Components Corp. (ECC) and later as TK-ECC, still making seat belts, until it was closed in 2004. Plant was later demolished.

|-

|&amp;nbsp;||Fisher Body Overseas Corp. - Kennedy Way plant||[[w:Belfast|Belfast]], [[w:Northern Ireland|Northern Ireland]]||[[w:United Kingdom|United Kingdom]] ||Seat Belt Buckles, Door switches, &amp; other automotive hardware||1982||?||Located in Kennedy Way Industrial Estate on Blackstaff Road in western Belfast. The Kennedy Way plant was part of Fisher Body Overseas Corp., part of GM Overseas Corp.

|-

|&amp;nbsp;||[[w:Flint, Michigan auto industry#Flint Plant #1|Flint Body Assembly]] (Fisher Body Flint Plant #1)||[[w:Flint, Michigan|Flint]], Michigan||United States||Bodies for Buick and later also Chevrolet &amp; Oldsmobile&lt;br /&gt;||1923||1987||Located at 4000-4500 S. Saginaw St. Originally a [[w:Durant Motors|Durant Motors]] plant. Bought by GM in 1926. Became Fisher Body Plant No. 1 - Flint. Supplied bodies to the Buick plant in Flint (later known as Buick City). After Buick City switched to unibody, fwd cars for 1986, Flint Body began supplying bodies for G-cars built at the Pontiac Assembly plant in Pontiac, MI. Closed in Dec. 1987 when G-body production at Pontiac Assembly ended. Last body built was a Buick Regal Grand National to be completed at Pontiac Assembly. Most of the site was demolished and the remainder was converted into the Great Lakes Technology Center. GM leased space there for R&amp;D and offices (including AC Rochester world headquarters) until 2009. Various medical-related companies now occupy much of the property. The original administration building at 4300 S. Saginaw St. still stands as of 2022 and still has a Fisher Body logo at the top of the front of the building in the center.  

|- 

|&amp;nbsp;||[[w:Flint, Michigan auto industry#Flint V8 Engine Plant/Flint Engine South|Chevrolet-Flint (V8) Engine Plant]] (Van Slyke Road)||[[w:Flint, Michigan|Flint, Michigan]]||United States||[[w:Chevrolet small-block engine (first and second generation)|Chevrolet small-block V8]]&lt;br /&gt;[[w:Chevrolet Turbo-Thrift engine|Chevrolet Turbo-Thrift I6]]&lt;br /&gt;[[w:Chevrolet 153 4-cylinder engine|Chevrolet 153 4-cylinder engine]]&lt;br /&gt;[[w:List of Isuzu engines#Isuzu G engine|Isuzu G140 &amp; G161Z SOHC gas&lt;br&gt; 4-cylinder engine for Chevy Chevette &amp; Pontiac 1000/Acadian]]&lt;ref&gt;{{cite news| title = 1975, Chevrolet Turns to Opel for the New Fuel-Saving Chevette| url = https://web.archive.org/web/20180116081057/https://history.gmheritagecenter.com/wiki/index.php/1975%2C_Chevrolet_Turns_to_Opel_for_the_New_Fuel-Saving_Chevette| archive-date = 2018-01-16| publisher = General Motors| access-date = 2014-06-05| url-status = dead}}&lt;/ref&gt;||1954||1999||Located at 3848 Van Slyke Road, down the block from the Flint Truck Assembly Plant. Only V8 engines were made until 1961, when 4 &amp; 6 cylinder engines began to be made for the 1962 Chevy II. Around 45 million Chevy small-block V8 engines were built at this plant. Plant closed in 1999 and was demolished. Land is now used by a new paint shop for the [[w:Flint Truck Assembly|Flint Truck Assembly Plant]]. The new paint shop (Flint Assembly Paint Operations) was announced in December 2013 and opened in 2016, replacing the previous paint shop inside the assembly plant. 

|- 

|1 (1928-1947)||[[w:Flint, Michigan auto industry#Flint Manufacturing Div./Delphi Flint West/Flint Tool and Die|Chevrolet-Flint Manufacturing Complex]] (&quot;Chevy in the Hole&quot;) /&lt;br /&gt; Flint West||[[w:Flint, Michigan|Flint, Michigan]]||United States||[[w:Chevrolet|Chevrolet]] vehicles including [[w:Chevrolet Series 490|Chevrolet Series 490]]&lt;br /&gt;[[w:Chevrolet Superior|Chevrolet Superior]]&lt;br /&gt;[[w:Chevrolet Series AA Capitol|Chevrolet Series AA Capitol]]&lt;br /&gt;[[w:Chevrolet Series AB National|Chevrolet Series AB National]]&lt;br /&gt;[[w:Chevrolet Series AC International|Chevrolet Series AC International]]&lt;br /&gt;[[w:Chevrolet Series AD Universal|Chevrolet Series AD Universal]]&lt;br /&gt;[[w:Chevrolet Series AE Independence|Chevrolet Series AE Independence]]&lt;br /&gt;[[w:Chevrolet Series BA Confederate|Chevrolet Series BA Confederate]]&lt;br /&gt;[[w:Chevrolet Standard Six|Chevrolet Standard Six]]&lt;br /&gt;[[w:Chevrolet Series CA Eagle / Master|Chevrolet Series CA Eagle / Master]]&lt;br /&gt;[[w:Chevrolet Master|Chevrolet Master]]&lt;br /&gt;[[w:Chevrolet Deluxe|Chevrolet Deluxe]]&lt;br /&gt;[[w:Chevrolet Stylemaster|Chevrolet Stylemaster]]&lt;br /&gt;[[w:Chevrolet Fleetmaster|Chevrolet Fleetmaster]]&lt;br /&gt;[[w:Chevrolet AK Series|Chevrolet AK Series]]&lt;br /&gt;[[w:Chevrolet Suburban|Chevrolet Suburban]] (Gen 1 &amp; 2)&lt;br /&gt;&lt;br /&gt;[[w:Chevrolet|Chevrolet]] engines including [[w:Chevrolet Inline-4 engine#171|Chevrolet Inline-4 engine]]&lt;br /&gt;[[w:Chevrolet Stovebolt engine|Chevrolet Stovebolt / Blue Flame I6]]&lt;br /&gt;||1913||2004||Located at 300 N. Chevrolet Ave. (formerly known as Wilcox Street). This was Chevrolet's home plant. It predated Chevrolet becoming part of GM in 1918. The complex originally included metal stamping, body assembly, vehicle assembly, engine assembly, and various component manufacturing plants. On January 11, 1940, the 25 millionth GM vehicle built in the US, a 1940 Chevrolet Special Deluxe Sedan, was built here. Plant 2 (vehicle assembly) &amp; 2A (Fisher Body) were replaced by new plants on Van Slyke Road elsewhere in Flint in 1947 (now the [[w:Flint Truck Assembly|Flint Truck Assembly Plant]]). Plant 4 was the engine plant. It closed in 1984 but was ultimately reopened later. In 1987, the complex was taken over by the AC Spark Plug division and became AC Spark Plug Flint West. In 1988, it became AC Rochester Flint West, and in 1994 AC Delco Systems Flint West following further consolidations. In early 1995, it was renamed Delphi Flint West. Around this time, plants in the complex began to be demolished until Plant 4 closed in 2004 and was subsequently demolished. Plant 4 last made generators and fuel filters. Building 35 still exists as part of [[w:Kettering University|Kettering University]]. It is now the C.S. Mott Science and Engineering Building after the addition of another floor and a new façade. Plant 38 still exists as GM's Flint Tool &amp; Die plant. All the other buildings are gone. Much of the property is being redeveloped into a park called [[w:Chevy Commons|Chevy Commons]].  

|- 

|&amp;nbsp;||[[w:Flint North|Flint North]] Powertrain||[[w:Flint, Michigan|Flint, Michigan]]||United States||[[w:Buick V8 engine|Buick V8 engine]]&lt;br /&gt;[[w:Buick V6 engine|Buick V6 engine]]&lt;br /&gt;Engine Components&lt;br /&gt;[[w:Dynaflow|Dynaflow]] transmissions&lt;br /&gt;transmission components&lt;br /&gt; torque converters&lt;br /&gt;coil springs||1905||2010||Complex was made up of several factories. Flint North is the part of the Buick City factory complex north of Leith St. stretching north to E. Pierson Rd. [[w:Liberty L-12|Liberty aircraft engines]] were made here during WWI. Factory 36 was the engine plant. Factory 36 opened in 1952 and closed in 2008. The remainder of the complex closed by December 2010. Demolished by 2012. Part of the site (1225 E. Marengo Ave.) is now occupied by American SpiralWeld Pipe Co.

|- 

||7||[[w:Arlington Assembly#History|Fort Worth Assembly]]||[[w:Fort Worth, TX|Fort Worth, Texas]]||United States||[[w:Chevrolet Series 490|Chevrolet Series 490]]||1917||1924 

|Built by Chevrolet before it became part of GM. Located at 2601 W. 7th St. (then known as Arlington Heights Blvd.). Is across the street from what is now Montgomery Plaza. A 3rd story was added to the building in 1920. Closed due to flood damage from the April 1922 flooding of the Trinity River and the subsequent imposition of flood-control taxes.&lt;ref&gt;https://books.google.com/books?id=mTvuAwAAQBAJ&amp;dq=1920+fort+worth+chevrolet+factory&amp;pg=PA52 Lost Fort Worth, page 52&lt;/ref&gt; Montgomery Ward leased the empty Chevy plant between 1924 and 1928 to house a temporary store while its main Fort Worth facility was built across what is now West Seventh Street. That building is now Montgomery Plaza. The Chevy plant was later used by various different companies including GM's Frigidaire division as a sales and warehouse facility and later by Tandy Corp., first for its Radio Shack division and later for its corporate HQ. Demolished in 1986. Site  is now Olympus 7th Street Station, a luxury apartment building.

|- 

|G &lt;br /&gt;(1960-1964 [[w:Chevrolet|Chevrolet]] and 1965-1989)&lt;br /&gt;&lt;br /&gt; B (Pre-1960 [[w:Oldsmobile|Oldsmobile]])&lt;br /&gt;&lt;br /&gt; F (Pre-1960 [[w:Pontiac (automobile)|Pontiac)]]&lt;br /&gt;&lt;br /&gt; 7 (Pre-1960 [[w:Buick|Buick]])||[[w:Framingham Assembly|Framingham Assembly]]||[[w:Framingham, Massachusetts|Framingham, Massachusetts]]||United States||[[w:General Motors A platform (1925)#1964|GM rwd A-bodies]]: [[w:Chevrolet Chevelle|Chevrolet Chevelle]] (1965-1969), [[w:Pontiac Tempest|Pontiac Tempest]] (1967-1970), [[w:Pontiac LeMans|Pontiac LeMans]] (1967-1972, 1974-1976), [[w:Pontiac GTO|Pontiac GTO]] (1966-1969, 1971-1972), [[w:Oldsmobile Cutlass|Oldsmobile Cutlass]] (1967-1981), [[w:Oldsmobile Cutlass Supreme|Oldsmobile Cutlass Supreme]] (1967-1981), [[w:Oldsmobile 442|Oldsmobile 442]] (1967-1977), [[w:Oldsmobile Vista Cruiser|Oldsmobile Vista Cruiser]] (1968-1977), [[w:Buick Skylark#Third generation (1968–1972)|Buick Skylark]] (1970-1972), [[w:Buick GS|Buick GS]] (1970-1972), [[w:Buick Century|Buick Century]] (1973-1981), [[w:Buick Regal|Buick Regal]] (1973-1981) 

[[w:General Motors A platform (1982)|GM fwd A-bodies]]: [[w:Chevrolet Celebrity|Chevrolet Celebrity]] (1982-1988), [[w:Pontiac 6000|Pontiac 6000]] (1982), [[w:Oldsmobile Cutlass Ciera|Oldsmobile Cutlass Ciera]] (1983-1989), [[w:Buick Century#Fifth generation (1982–1996)|Buick Century]] (1989) 

||1948||1989|| Located at 63 Western Ave. First vehicle produced was a 1948 Buick on February 26, 1948. Was originally part of the [[w:Buick-Oldsmobile-Pontiac Assembly Division|Buick-Oldsmobile-Pontiac Assembly Division]]. Framingham is the only BOP Assembly Division plant to switch to the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Framingham switched to Chevrolet Assembly Division in August 1959 [https://www.worthpoint.com/worthopedia/gm-framingham-ma-canada-pontiac-buick-olds-plant]. Framingham began making Chevrolet passenger cars for 1960. BOP Assembly Division became GM Assembly Division in 1965. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were then gradually transferred to the GM Assembly Division. Framingham Assembly joined the GM Assembly Division in 1968. Idled October 1, 1982 but reopened March 14, 1983. Closed August 1, 1989. Sold to ADESA to use as a vehicle auction site. &lt;br/&gt;Past models: &lt;br/&gt; [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1960-1966), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1960-1966), [[w:Chevrolet Impala|Chevrolet Impala]] (1960-1966), [[w:Chevrolet Chevy II / Nova#First generation (1962–1965)|Chevrolet Chevy II/Nova]] (1962-1963), [[w:Buick Century#Second generation (1954–1958)|Buick Century]] (B-body), [[w:Buick Roadmaster|Buick Roadmaster]] (1949-1950, 1955, 1958), [[w:Buick Special#1949–1958|Buick Special]] (1952-1953, 1955-1958), [[w:Buick Super|Buick Super]] (1954), [[w:Oldsmobile 88|Oldsmobile 88]], [[w:Oldsmobile 98|Oldsmobile 98]], [[w:Pontiac Bonneville|Pontiac Bonneville]] (1958), [[w:Pontiac Chieftain|Pontiac Chieftain]] (1951, 1954, 1956), [[w:Pontiac Star Chief|Pontiac Star Chief]] (1955, 1957, 1959) 

|- 

|&amp;nbsp;||General Motors France S.A.||[[w:Gennevilliers|Gennevilliers]]||[[w:France|France]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Buick|Buick]]||1939||1940||Operations interrupted by German invasion of France and seizure of the plant in 1940 during WWII. 

|- 

|Z (1965-1982)&lt;br /&gt;&lt;br /&gt;H (1963-1964 [[w:Chevrolet|Chevrolet]] and [[w:GMC (automobile)|GMC]])&lt;br /&gt;&lt;br /&gt;F (1964 [[w:Pontiac (automobile)|Pontiac]] and [[w:Oldsmobile|Oldsmobile]])&lt;br /&gt;&lt;br /&gt;3 (1964 [[w:Buick|Buick]])||[[w:Fremont Assembly|Fremont Assembly]]||[[w:Fremont, California|Fremont, California]]||United States||[[w:Buick Century|Buick Century]] (1973-1981)&lt;br /&gt;[[w:Buick GS|Buick GS]] (1965-1972)&lt;br /&gt;[[w:Buick Regal|Buick Regal]] (1973-1981)&lt;br /&gt;[[w:Buick Skylark|Buick Skylark]] (1964-1972)&lt;br /&gt;[[w:Buick Special|Buick Special]] (1964-1969)&lt;br /&gt;[[w:Buick Sport Wagon|Buick Sport Wagon]] (1965)&lt;br /&gt;[[w:Chevrolet K5 Blazer#1973–1991|Chevrolet K5 Blazer]] (1977-1979)&lt;br /&gt;[[w:Chevrolet C/K|Chevrolet C/K]] (1963-1982)&lt;br /&gt;[[w:Chevrolet Celebrity|Chevrolet Celebrity]] (1982)&lt;br /&gt;[[w:Chevrolet Chevelle|Chevrolet Chevelle]] (1964-1969, 1973-1977)&lt;br /&gt;[[w:Chevrolet El Camino|Chevrolet El Camino]] (1964-1969, 1973-1981)&lt;br /&gt;[[w:Chevrolet Malibu|Chevrolet Malibu]] (1978-1981)&lt;br /&gt;[[w:Chevrolet Monte Carlo|Chevrolet Monte Carlo]] (1973-1981)&lt;br /&gt;[[w:Chevrolet Suburban|Chevrolet Suburban]] (1964-1971)&lt;br /&gt;[[w:GMC C/K|GMC C/K]] (1963-1982)&lt;br /&gt;[[w:GMC Caballero|GMC Caballero]] (1978-1981)&lt;br /&gt;[[w:Chevrolet K5 Blazer#1973–1991|GMC Jimmy]] (1977-1979)&lt;br /&gt;[[w:GMC Sprint|GMC Sprint]] (1973-1977)&lt;br /&gt;[[w:GMC Suburban|GMC Suburban]] (1964-1971)&lt;br /&gt;[[w:Oldsmobile Cutlass|Oldsmobile Cutlass]] (1964-1972)&lt;br /&gt;[[w:Oldsmobile Cutlass Ciera|Oldsmobile Cutlass Ciera]] (1982)&lt;br /&gt;[[w:Oldsmobile Cutlass Supreme|Oldsmobile Cutlass Supreme]] (1966-1972)&lt;br /&gt;[[w:Oldsmobile 442|Oldsmobile 442]] (1964-1972)&lt;br /&gt;[[w:Oldsmobile Vista Cruiser|Oldsmobile Vista Cruiser]] (1965-1966)&lt;br /&gt;[[w:Pontiac Grand Prix#Third generation (1969–1972)|Pontiac Grand Prix]] (1970)&lt;br /&gt;[[w:Pontiac LeMans|Pontiac LeMans]] (1964-1974)&lt;br /&gt;[[w:Pontiac GTO|Pontiac GTO]] (1964-1973)&lt;br /&gt;[[w:Pontiac Tempest|Pontiac Tempest]] (1964-1969)||1963||1982||Located at 45500 Fremont Blvd.&lt;br /&gt;

Operated from 1963-1982 as a GM factory. Was originally part of the [[w:Buick-Oldsmobile-Pontiac Assembly Division|Buick-Oldsmobile-Pontiac Assembly Division]] though it also built Chevrolet passenger cars from the beginning. Fremont built GM's midsize A-bodies. Was the first BOP Assembly Division plant to also build Chevrolet and GMC trucks. Regular truck production began June 10, 1963. First production car built September 3, 1963. BOP Assembly Division became GM Assembly Division in 1965. Plant was idled March 1982.&lt;br /&gt;

From 1984-2010, operated as [[w:NUMMI|New United Motor Manufacturing Inc. (NUMMI)]], which was a 50/50 joint venture between GM and [[w:Toyota|Toyota]] and assembled both GM and Toyota vehicles.&lt;br /&gt;

Sold to [[w:Tesla Motors|Tesla, Inc.]] in May 2010.&lt;ref&gt;{{cite news|author=Sam Abuelsamid|title=Tesla to buy old resources from GM, Toyota for NUMMI plant|url=http://www.autoblog.com/2010/08/22/tesla-to-buy-old-resources-from-gm-toyota/|access-date=20 August 2015|publisher=Autoblog.com|date=August 22, 2010}}&lt;/ref&gt; Tesla began production at Fremont in 2012.

|- 

|P||[[w:Fabryka Samochodów Osobowych|FSO]]||[[w:Warsaw|Warsaw]]||[[w:Poland|Poland]]||[[w:Opel Astra#F|Opel Astra]]&lt;br /&gt;[[w:Opel Vectra#Vectra B (1995–2002)|Opel Vectra]]||1994||2000||Built by an [[w:Fabryka Samochodów Osobowych|FSO]] - GM joint venture operating out of a converted old FSO warehouse.  

|- 

|W||[[w:Fabryka Samochodów Osobowych|FSO]]||[[w:Warsaw|Warsaw]]||[[w:Poland|Poland]]||[[w:Chevrolet Aveo (T200)|Chevrolet Aveo]]||2007||2011||Built by [[w:Fabryka Samochodów Osobowych|FSO]] for GM as part of a joint venture between [[w:Ukrainian Automobile Corporation|UkrAvto]] (parent of FSO) &amp; GM. [[w:Ukrainian Automobile Corporation|Ukravto]] owned 60% &amp; [[w:GM Daewoo|GM Daewoo]] owned 40%. The production license ended in 2011 &amp; was not renewed. 

|- 

|&amp;nbsp;||[[General Motors Gmbh]]||[[w:Berlin|Berlin]]||Germany||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt;[[w:Oakland (automobile)|Oakland]]&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]]&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:Cadillac|Cadillac]]||1927||1932||Replaced Hamburg plant. Located in Borsigwalde area of Berlin. Also predates the acquisition of [[w:Opel|Opel]] by GM.  

|- 

|&amp;nbsp;||[[General Motors Gmbh]]||[[w:Hamburg|Hamburg]]||Germany||[[w:Chevrolet|Chevrolet]] trucks||1926||1927||GM's first German plant predating the acquisition of [[w:Opel|Opel]]. Located in a leased warehouse.  

|- 

|&amp;nbsp;||[[General Motors Ltd.]]||[[w:Hendon|Hendon]], [[w:England|England]]||United Kingdom||[[w:Chevrolet|Chevrolet]] &lt;br /&gt; [[w:GMC (automobile)|GMC]] ||1924||1930||GM's first British plant predating the acquisition of [[w:Vauxhall Motors|Vauxhall]]. Operated out of a leased plant. When Chevrolet production was moved to Luton in 1930, Hendon was used for parts distribution. Later, Frigidaire made appliances at Hendon. In 1970, Hendon began producing steering columns. In 1971, more automotive components began to be produced in place of Frigidaire appliances. In 1980, GM sold the Hendon site for redevelopment but leased back an area for construction of a new plant for Saginaw Steering Gear. The new plant opened in 1981. See listing for &quot;Saginaw Steering Gear Overseas Corp. - Southampton plant&quot; for more details.

|- 

|&amp;nbsp;||[[General Motors Ltd.]]||[[w:Southampton|Southampton]], [[w:Hampshire|Hampshire]], [[w:England|England]]||United Kingdom||[[w:Chevrolet|Chevrolet]]||1938||1946||Located on West Bay Road in the New Dock area of Southampton. Operations interrupted by German bombing of the UK during WWII. Plant was bombed in 1940 &amp; 1941. Plant was reoccupied in 1946. Plant acquired by GM Ltd. in 1951 and converted to produce automotive components in 1952. See listing for &quot;AC Spark Plug Overseas Corp. - Southampton plant&quot; for more details.

|- 

|&amp;nbsp;||[[w:Ghandhara Industries|Ghandhara Industries]]||[[w:Karachi|Karachi]], [[w:Sindh|Sindh]]||[[w:Pakistan|Pakistan]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford trucks and buses]] including [[w:Bedford TJ|Bedford TJ]]&lt;br /&gt;[[w:Holden|Holden]]||1953||1970's||Originally a GM owned plant (General Motors Overseas Distribution Corporation). Sold to [[w:Ghandhara Industries|Ghandhara Industries]] Ltd. in 1963. Nationalized in 1972, it then became National Motors Ltd. Privatized to the [[w:Bibojee Group|Bibojee Group]] in 1992 who reverted back to the previous name, Ghandhara Industries. Ghandara Industries assembles Isuzu vehicles today. 

|- 

|&amp;nbsp;||[[GM-Auto]]||[[w:Saint-Petersburg|Saint-Petersburg]]||[[w:Russia|Russia]]||[[w:Chevrolet Cruze|Chevrolet Cruze]]&lt;br /&gt;[[w:Opel Astra|Opel Astra]] 

[[w:Chevrolet Trailblazer (SUV)#Second generation (RG; 2011)|Chevrolet Trailblazer]] 

[[w:Chevrolet Captiva#First generation (C100, C140; 2006)|Chevrolet Captiva]]&lt;br /&gt;[[w:Opel Antara|Opel Antara]] 

||2007||2015||Includes operations at the temporary &quot;Arsenal plant&quot; &amp; the permanent plant in [[w:Shushary, Saint Petersburg|Shushary]]. GM ceased most operations in Russia back in 2015 and the GM-Auto plant closed. Sold to Hyundai Motor in 2020.  

|- 

|&amp;nbsp;||[[w:GM-AvtoVAZ|GM-AvtoVAZ]]||[[w:Tolyatti|Togliatti]]||[[w:Russia|Russia]]||[[w:Chevrolet Niva|Chevrolet Niva]]&lt;br /&gt;[[w:Chevrolet Viva|Chevrolet Viva]]||2002||2019||Was originally owned 41.5% by GM, 41.5% by AvtoVAZ, &amp; 17% by [[w:EBRD|EBRD]]. In 2012, [[w:EBRD|EBRD]] was bought out &amp; GM-AvtoVAZ became 50/50 owned by GM &amp; AvtoVAZ. The GM-AvtoVAZ joint venture was dissolved in 2019 when AvtoVAZ bought out GM. The Chevrolet Niva was renamed Lada Niva Travel during 2020. AvtoVAZ was a part of [[w:Renault Group|Renault Group]] from 2016 until 2022. 

|- 

|4||GM España S.A.||[[w:Figueruelas|Figueruelas]], [[w: Zaragoza (province)| Zaragoza (province)]]||[[w:Spain|Spain]]||[[w:Opel Corsa|Opel/Vauxhall Corsa]] A, B, C, D, E (5 door, van)&lt;br /&gt;[[w:Opel Meriva|Opel/Vauxhall Meriva]] A, B&lt;br /&gt;[[w:Opel Combo#Combo C (2001-2012)|Opel/Vauxhall/Holden Combo]] C&lt;br /&gt;[[w:Opel Tigra#Tigra A (1994–2000)|Opel/Vauxhall Tigra A]]&lt;br /&gt;[[w:Vauxhall Nova|Vauxhall Nova]]&lt;br /&gt;[[w:Holden Barina#Third generation (SB; 1994–2000)|Holden Barina (SB)]]&lt;br /&gt;[[w:Holden Barina#Fourth generation (XC; 2001–2005)|Holden Barina (XC)]]||1982||2017|| [[w:Adam Opel AG|Opel plant]]. Sold to [[w:PSA Group|PSA Group]] in 2017. Part of [[w:Stellantis|Stellantis]] since 2021. 

|- 

|&amp;nbsp;||GM Indonesia||Pondok Ungu, [[w:Bekasi|Bekasi]], [[w:West Java|West Java]]||[[w:Indonesia|Indonesia]]||After reopening:&lt;br /&gt; [[w:Chevrolet Spin|Chevrolet Spin]]&lt;br /&gt;&lt;br /&gt;Before temporary closure in 2005:&lt;br /&gt; [[w:Chevrolet S-10 Blazer#Second generation (1995)|Chevrolet Blazer]]&lt;br /&gt;[[w:Opel Blazer|Opel Blazer]]&lt;br /&gt;[[w:Opel Astra#F|Opel Optima]]&lt;br /&gt;[[w:Opel Vectra#Vectra A (1988–1995)|Opel Vectra]]||1995||2015||PT Garmak Motor assembled models under license from GM beginning in 1976, before the establishment of their joint venture with GM in 1993. These license built models include: [[w:Bedford Vehicles|Bedford]] trucks, [[w:Bedford HA#The BTV|Morina]], [[w:Opel Rekord Series E|Opel Rekord E 3-d panel van]], [[w:Opel Kadett#Kadett D (1979–1984)|Opel Kadett D]], [[w:Isuzu Faster#First generation (1972–1980)|Chevrolet LUV (Mk 1)]], [[w:Isuzu Faster#Second generation (1980–1988)|Chevrolet LUV (Mk II)]], &amp; [[w:Isuzu Trooper#First generation (1981–1991)|Chevrolet Trooper/Stallion]].  

Originally established as PT General Motors Buana Indonesia, which was owned 60% by GM and 40% by PT Garmak Motor. GM bought out Garmak in 1997 taking 100% of the shares. The assembly plant was closed from 2005-2011 and reopened in 2012 to make the Chevy Spin. Closed again in June 2015. 

|- 

|&amp;nbsp;||GM Java||[[w:Tanjung Priok|Tanjung Priok]], [[w:North Jakarta|North Jakarta]], [[w:Jakarta|Jakarta]]||[[w:Indonesia|Indonesia]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Opel|Opel]] ([[w:Opel 1.2 Liter|1.2 Liter]])&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]] ([[w:Vauxhall 10-4|10-4]])||1927||1953||First Car Factory in what is now Indonesia (at the time, it was the Dutch East Indies). GM pulled out of Indonesia in 1954 and liquidated the company by 1956. Sold to P.N. Gaja Motors, which assembled the Opel Rekord and Kadett in the 1960's. Eventually became part of Astra International and its joint ventures with Toyota/Daihatsu.  

|- 

|&amp;nbsp;||GM Malaysia Sdn. Bhd.||[[w:Tampoi, Johor|Tampoi]], [[w:Johor|Johor]]||[[w:Malaysia|Malaysia]]||[[w:Opel Ascona|Opel Ascona]]&lt;br /&gt;[[w:Opel Commodore|Opel Commodore]]&lt;br /&gt;[[w:Opel Gemini|Opel Gemini]]&lt;br /&gt;[[w:Opel Kadett|Opel Kadett]]&lt;br /&gt;[[w:Opel Manta|Opel Manta]]&lt;br /&gt;[[w:Opel Rekord|Opel Rekord]]&lt;br /&gt;[[w:Bedford HA#The BTV|Bedford Harimau]]&lt;br /&gt;[[w:Holden|Holden]]||1968||1982||Originally Capital Motor Assembly Corp., which assembled Opel models under license from GM beginning in 1968. These license built models include: [[w:Opel Commodore|Opel Commodore]] A, [[w:Opel Kadett|Opel Kadett B]], [[w:Opel Rekord Series C|Opel Rekord C]], &amp; components. Capital Motor also assembled cars for Honda and Datsun (Nissan). GM bought Capital Motor Assembly in 1971 and renamed it GM Malaysia. Malaysian government policies that said Malaysians had to own a majority of local auto assembly plants forced GM to sell GM Malaysia to Oriental Holdings in 1980 which then renamed the unit Oriental Assemblers. Assembly of GM vehicles ended in 1982. Oriental Assemblers continued making Honda cars at this plant until around 2004.  

|- 

|&amp;nbsp;||GM Philippines, Inc.||[[w:Paco, Manila|Paco district]], [[w:Manila|Manila]]||[[w:Philippines|Philippines]]||[[w:Buick Electra|Buick Electra]]&lt;br /&gt;[[w:Chevrolet Bel Air|Chevrolet Bel Air]]&lt;br /&gt;[[w:Chevrolet Camaro (first generation)|Chevrolet Camaro]]&lt;br /&gt;[[w:Chevrolet Impala|Chevrolet Impala]]&lt;br /&gt;[[w:Chevrolet Malibu|Chevrolet Malibu]]&lt;br /&gt;Chevrolet trucks&lt;br /&gt;[[w:Holden EH|Holden EH]]&lt;br /&gt;[[w:Holden HD|Holden HD]]&lt;br /&gt;[[w:Holden HR|Holden HR]]&lt;br /&gt;[[w:Holden HK|Holden HK]]&lt;br /&gt;[[w:Holden HT|Holden HT]]&lt;br /&gt;[[w:Holden HG|Holden HG]]&lt;br /&gt;[[w:Holden HQ|Holden HQ]]&lt;br /&gt;[[w:Holden Torana|Holden Torana]]&lt;br /&gt;[[w:Isuzu Gemini|Isuzu Gemini]]&lt;br /&gt;[[w:Opel Ascona|Opel Ascona]]&lt;br /&gt;[[w:Opel Kadett|Opel Kadett]]&lt;br /&gt;[[w:Opel Manta|Opel Manta]]&lt;br /&gt;[[w:Opel Rekord|Opel Rekord]]&lt;br /&gt;[[w:Pontiac Parisienne#Philippines|Pontiac Parisienne]]&lt;br /&gt;[[w:Vauxhall Victor|Vauxhall Victor]]&lt;br /&gt;[[w:Vauxhall Viva|Vauxhall Viva]]&lt;br /&gt;[[w:Vauxhall VX4/90|Vauxhall VX4/90]]&lt;br /&gt;[[w:Bedford HA#The BTV|GM Amigo/Tiger/Harabas]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford trucks]] ||1953||1985||Originally Yutivo Sons Hardware Co. Yutivo assembled various models under license from GM beginning in 1953. GM bought a 49% stake in Yutivo in 1972 and renamed it GM Philippines. Isuzu invested in the company in 1979 and it was renamed GM Pilipinas, Inc. Assembly of GM vehicles ended in 1985 and GM sold the plant to Isuzu in 1994. Isuzu closed this plant and company in 1995 and replaced it with a new plant in Biñan, Laguna owned by a new subsidiary (Isuzu Philippines Corporation).  

|- 

|G||[[w:GM Manufacturing Poland|GM Manufacturing Poland Sp. z o.o.]]||[[w:Gliwice|Gliwice]]||[[w:Poland|Poland]]||[[w:Opel Astra#Astra K (B16; 2015)|Opel Astra]] K (5-door)&lt;br /&gt;[[w:Holden Astra#Seventh generation (BK, BL; 2016)|Holden Astra (BK)]] (5-door)&lt;br /&gt;[[w:Opel Astra#Astra J (P10; 2009)|Opel/Vauxhall Astra J]] (3-door, 4-door sedan, 5-door)&lt;br /&gt;[[w:Opel Astra#Astra H (A04; 2004)|Opel Astra Classic III]] sedan&lt;br /&gt;[[w:Holden Astra#Sixth generation (PJ; 2015)|Holden Astra (PJ)]] (GTC, VXR)&lt;br /&gt;[[w:Opel Astra#Astra H (A04; 2004)|Opel Astra H]] sedan&lt;br /&gt;[[w:Opel Astra#Astra G (T98; 1998)|Opel Astra Classic II]]&lt;br /&gt;[[w:Holden Astra#Fourth generation (TS; 1998)|Holden Astra Classic (TS)]]&lt;br /&gt;[[w:Opel Astra#Astra F (T92; 1992)|Opel Astra Classic I]]&lt;br /&gt;[[w:Opel Agila#First generation (H00; 2000)|Opel/Vauxhall Agila A]]&lt;br /&gt;[[w:Suzuki Solio#First generation (MA63S/MA64S/MA32S; 1999)|Suzuki Wagon R+ (2005-2007)]]&lt;br /&gt;[[w:Opel Cascada|Opel/Vauxhall Cascada]]&lt;br /&gt;[[w:Buick Cascada|Buick Cascada]]&lt;br /&gt;[[w:Holden Cascada|Holden Cascada (CJ)]]&lt;br /&gt;[[w:Opel Zafira#Zafira B (2005)|Opel/Vauxhall Zafira B]]||1998||2019|| [[w:Adam Opel AG|Opel]] plant. Sold to [[w:PSA Group|PSA Group]] in 2017. Continued to supply the [[w:Buick Cascada|Buick Cascada]] to GM through 2019. Part of [[w:Stellantis|Stellantis]] since 2021.   

|-

|&amp;nbsp;||GM Powertrain Fredericksburg||[[w:Fredericksburg, Virginia|Fredericksburg, Virginia]]||United States||Torque converter clutches for automatic transmissions||1979||2010|| Located at 11032 Tidewater Trail. Originally part of Delco Moraine Division, which bought the plant in 1978 from American Poclain. Moved to GM Powertrain division in 1993. Sold to idX Corp. in 2017.  

|-  

|&amp;nbsp;||[[w:GM Powertrain Poland|GM Powertrain Poland]]||[[w:Tychy|Tychy]]||[[w:Poland|Poland]]||Diesel engines including the Isuzu [[w:Circle L engine|Circle L engine]]||1999||2017|| [[w:Adam Opel AG|Opel]] plant. Originally founded as Isuzu Motors Polska (ISPOL) in 1996. GM bought 60% in 2002 &amp; the remaining 40% in 2013. Sold to [[w:PSA Group|PSA Group]] along with Opel in 2017. Part of [[w:Stellantis|Stellantis]] since 2021. 

|-  

|&amp;nbsp;||[[w:Grand Blanc Metal Center|Grand Blanc Metal Center]]||[[w:Grand Blanc, Michigan|Grand Blanc, Michigan]]||United States||Metal stampings and metal fabrication of body components, Tooling jigs-and-fixtures||1942||2013||Located at 10800 S. Saginaw St. Originally built by the US govt. and opened in 1942 to build tanks. Also known as the Fisher Body Tank Plant as it was operated by GM's Fisher Body Div. Built [[w:M4 Sherman|M4 Sherman]] (M4A2, M4A3 &amp; M4A3E2) and [[w:M26 Pershing|M26 Pershing]] (T26E3) tanks as well as M10 &amp; M10A1 &quot;Wolverine&quot; Tank Destroyers during WWII and [[w:M48 Patton|M48 Patton]] (M48 and M48A1) tanks beginning in 1952 for the Korean War. Grand Blanc also made a 90mm main gun that Grand Blanc installed on the last 300 M10A1s built at Grand Blanc, thus converting them into the M36 &quot;Jackson&quot;. The Grand Blanc-built 90mm main gun was also installed on other M10A1s by other companies and by Grand Blanc on the M4A3 Sherman tank to create the M36B1 &amp; M36B2 tank destroyers. Grand Blanc also supplied 2,445 turrets and 1,511 hulls for the 2,507 M18 Hellcats built by the Buick Division. Production ended in 1945 as WWII wound down. Buick then leased Grand Blanc and used it as a warehouse from 1947 until Fisher Body bought it in 1951. The M48 Patton was built from 1952-1955. Converted in 1955 into an automotive body metal fabricating plant. Became part of GM's Metal Fabricating Division in 1994 and became Grand Blanc Weld Tool Center in 2002, making tooling for GM. Closed July 2013. Most of the work done at Grand Blanc was transferred to Parma, OH. Now called Grand Blanc Center, apparently used as a warehouse.

|- 

|&amp;nbsp;||Grand Rapids Metal Center||[[w:Wyoming, Michigan|Wyoming, Michigan]]||United States||&amp;nbsp;||1936||2009||Located at 300 36th Street SW. Metal fabricating plant. Demolished.  

|- 

|&amp;nbsp;||Guide Lamp Division||[[w:Anderson, Indiana|Anderson, Indiana]]||United States||Headlamp, Taillamp assemblies||1929||1998||GM bought Guide Motor Lamp Manufacturing Company in 1928, becoming part of the Delco Remy division initially before becoming the separate Guide Lamp Division in 1929. Guide Lamp Division was renamed Guide Division in 1975. Guide Division merged with Fisher Body in 1984 to create Fisher Guide. Fisher Guide then merged with the Inland Division in 1990 to form Inland Fisher Guide. In 1998, Guide operations were sold to [[w:Palladium Equity Partners|Palladium Equity Partners]] which turned the operation into Guide Corp. In 2007, Guide Corp. closed down.  

|- 

|H||[[w:General Motors India|Halol]]||[[w:Halol|Halol]], [[w:Gujarat|Gujarat]]||[[w:India|India]]||[[w:Chevrolet Sail#India|Chevrolet Sail U-VA]] (hatchback)&lt;br /&gt;[[w:Chevrolet Sail#India|Chevrolet Sail]] (sedan)&lt;br /&gt;[[w:Chevrolet Cruze|Chevrolet Cruze]]&lt;br /&gt;[[w:Chevrolet Tavera|Chevrolet Tavera]]||1995||2017||Past models: 

[[w:Chevrolet Aveo (T200)|Chevrolet Aveo]], [[w:Chevrolet SRV|Chevrolet SRV]] (sports hatch), [[w:Chevrolet Optra|Chevrolet Optra]], [[w:Chevrolet Enjoy|Chevrolet Enjoy]], [[w:Opel Corsa|Opel Corsa]](sedan), [[w:Opel Corsa|Opel Corsa Sail]] (hatchback), [[w:Opel Corsa|Opel Corsa Swing]](station wagon), [[w:Opel Astra|Opel Astra]]. &lt;br /&gt; 

The new [[w:General Motors India|GM India]] began as a 50/50 joint venture with [[w:Hindustan Motors|Hindustan Motors]] in 1994.The Halol plant was bought from [[w:Hindustan Motors|Hindustan Motors]] in 1995. GM bought out [[w:Hindustan Motors|Hindustan Motors]] in 1999.  

Sold to SAIC to produce [[w:MG Motor India|MG Motor India]] vehicles in 2017.  

|- 

|&amp;nbsp;||Fisher Body - Hamilton-Fairfield Stamping Plant||[[w:Hamilton, Ohio|Hamilton, Ohio]]||United States||Stampings &amp; Bodies for GM vehicles||1947||1988||Located at 4400 Dixie Highway. Now the Fisher Industrial Park.  

|- 

|&amp;nbsp;||Harrison Radiator Division - Moraine||[[w:Moraine|Moraine]], [[w:Ohio|Ohio]]||United States||Machining and assembly of automotive A/C compressors, valves, and accumulator dehydrators||1941||1999||Located at 3600 Dryden Road. Originally built for [[w:Frigidaire|Frigidaire]]. In 1975, automotive and appliance operations were split with the automotive operations becoming Delco Air Conditioning Division. [[w:Frigidaire|Frigidaire]] appliance division was sold in 1979. Delco Air Conditioning Division merged into Harrison Radiator Division in 1981. Spun off with [[w:Delphi Automotive Systems|Delphi Automotive Systems]] in 1999. Became Delphi Harrison Thermal Systems. Closed by Delphi in 2003. Demolished by 2005.  

|- 

|H1, H2,&lt;br&gt; H3, H4 [https://www.uniquecarsandparts.com.au/holden_identification]||Holden Acacia Ridge Plant||[[w:Acacia Ridge, Queensland|Acacia Ridge, Queensland]]||[[w:Australia|Australia]]||[[w:Holden|Holden]] models including:&lt;br /&gt; [[w:Holden HD|Holden HD]]&lt;br /&gt;[[w:Holden HR|Holden HR]]&lt;br /&gt;[[w:Holden HK|Holden HK]]&lt;br /&gt;[[w:Holden HT|Holden HT]]&lt;br /&gt;[[w:Holden HG|Holden HG]]&lt;br /&gt;[[w:Holden Torana|Holden Torana]]&lt;br /&gt;[[w:Holden HQ|Holden HQ]]&lt;br /&gt;[[w:Holden HJ|Holden HJ]]&lt;br /&gt;[[w:Holden HX|Holden HX]]&lt;br /&gt;[[w:Holden HZ|Holden HZ]]&lt;br /&gt;[[w:Holden Gemini#First generation|Holden Gemini TX, TC, TD, TE, TF, TG]]&lt;br /&gt;[[w:Holden Commodore (VC)|Holden Commodore (VC)]]&lt;br /&gt;[[w:Holden Camira|Holden Camira]]||1966||1984||[[w:Holden|Holden]] plant. Replaced Fortitude Valley plant.

|- 

|A||Holden Birkenhead Plant||[[w:Birkenhead, South Australia|Birkenhead, South Australia]]||[[w:Australia|Australia]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt;[[w:Oakland (automobile)|Oakland]]&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]]&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:Cadillac|Cadillac]]&lt;br /&gt;[[w:GMC (automobile)|GMC]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford]]&lt;br /&gt;[[w:Holden|Holden]]&lt;br /&gt;||1926||1981||[[w:Holden|Holden]] plant. Built by GM Australia before it merged with Holden's Motor Body Builders Ltd. Plant was closed from 1931 until 1938. Also produced military vehicles &amp; equipment during WWII. Before WWII, Birkenhead combined bodies made in Woodville with CKD chassis assembled in Melbourne. After WWII, Birkenhead assembled CKD chassis imported from the US, Canada, &amp; the UK and combined them with bodies made in Woodville. Once Holden brand cars started to be made in 1948, body and chassis components came from Woodville &amp; powertrain came from Fishermans Bend and complete cars were assembled in Birkenhead. Vehicle production ended in 1965 when the Elizabeth plant started making complete vehicles. Birkenhead was then used as an export boxing area, a parts warehouse, and also assembled earthmoving equipment for Terex (then owned by GM) from 1969 until the mid 1970's. 

|- 

|M,&lt;br&gt; J1, J2, J3, &lt;br&gt; and J4-J9||Holden Dandenong Plant||[[w:Dandenong|Dandenong]], [[w:Victoria, Australia|Victoria]]||[[w:Australia|Australia]]||[[w:Holden|Holden]] models including:&lt;br /&gt; [[w:Holden FE|Holden FE]]&lt;br /&gt;[[w:Holden FC|Holden FC]]&lt;br /&gt;[[w:Holden FB|Holden FB]]&lt;br /&gt;[[w:Holden EK|Holden EK]]&lt;br /&gt;[[w:Holden EJ|Holden EJ]]&lt;br /&gt;[[w:Holden EH|Holden EH]]&lt;br /&gt;[[w:Holden HD|Holden HD]]&lt;br /&gt;[[w:Holden HR|Holden HR]]&lt;br /&gt;[[w:Holden HQ|Holden HQ]]&lt;br /&gt;[[w:Holden HZ|Holden HZ]]&lt;br /&gt;[[w:Holden HK|Holden HK]]&lt;br /&gt;[[w:Holden Torana|Holden Torana]] LH, LX, UC&lt;br /&gt;[[w:Holden Sunbird|Holden Sunbird]] LX, UC&lt;br /&gt;[[w:Holden Commodore (VB)|Holden Commodore (VB)]]&lt;br /&gt;[[w:Holden Commodore (VC)|Holden Commodore (VC)]]&lt;br /&gt;[[w:Holden Commodore (VH)|Holden Commodore (VH)]]&lt;br /&gt;[[w:Holden Commodore (VK)|Holden Commodore (VK)]]&lt;br /&gt;[[w:Holden Commodore (VL)|Holden Commodore (VL)]]&lt;br /&gt;[[w:Holden Camira|Holden Camira]]&lt;br /&gt;[[w:Holden Nova|Holden Nova]] LE, LF &lt;br /&gt; [[w:Toyota Corolla (E90)#Australia|Toyota Corolla (E90)]]&lt;br /&gt;Bedford by Isuzu &amp; [[w:Isuzu|Isuzu]] trucks&lt;br /&gt;Body making&lt;br /&gt;Torque converters &amp; other components||1956|||1996||[[w:Holden|Holden]] plant. Also assembled Chevrolet trucks, Bedford vans &amp; trucks and Frigidaire appliances. Built the 1 millionth Holden (an EJ) in October 1962, the 2 millionth Holden (an HK) in March 1969, and the 4 millionth Holden (a VC Commodore) in June 1981. Vehicle production by Holden ceased in 1988, vehicle production by Toyota for itself and for Holden lasted from 1989-1994 under a plant lease agreement&lt;ref&gt;{{cite web |author=Takahiro Fujimoto |date=October 1998 |url=http://e-server.e.u-tokyo.ac.jp/cirje/research/dp/98/cf23/dp.pdf |title=Toyota Motor Manufacturing Australia in 1995: An Emergent Global Strategy |publisher=[[w:University of Tokyo|University of Tokyo]] |page=23 |archive-url=https://www.webcitation.org/5xJZkwEEX?url=http://e-server.e.u-tokyo.ac.jp/cirje/research/dp/98/cf23/dp.pdf |archive-date=2011-03-20 |url-status=dead }}&lt;/ref&gt;. Minor assembly until 1996. Then became known as Holden Service Parts Operations (HSPO) which manages the distribution and marketing of Holden service parts and accessories for the Holden dealer network and international customers.  

|- 

|L,&lt;br&gt;&lt;br&gt; L1, L2, &lt;br&gt; L3-L5||Holden Elizabeth Plant||[[w:Elizabeth, South Australia|Elizabeth, South Australia]]||[[w:Australia|Australia]]||[[w:Holden Berlina|Holden Berlina]]&lt;br /&gt;[[w:Holden Calais|Holden Calais]]&lt;br /&gt; [[w:Holden Caprice|Holden Caprice]]&lt;br /&gt; [[w:Holden Commodore|Holden Commodore]]&lt;br /&gt; [[w:Holden Ute|Holden Ute]]&lt;br /&gt; [[w:Holden Statesman|Holden Statesman]]&lt;br /&gt; [[w:Vauxhall VXR8|Vauxhall VXR8]]&lt;br /&gt;[[w:Chevrolet SS (2013)|Chevrolet SS]] (2014-2017)&lt;br /&gt;[[w:Chevrolet Caprice PPV|Chevrolet Caprice PPV]] (2011-2017)

|1959||2017||[[w:Holden|Holden]] manufacturing plant. Holden Vehicle Manufacturing Operations. Located at 180 Philip Highway. First opened as a body hardware plant making components, then expanded to making complete vehicle bodies in 1962, then expanded to making complete vehicles in 1965. Elizabeth became Holden’s only remaining car manufacturing plant in Australia in 1994. Built the 5 millionth Holden (a VN Calais) in August 1990, the 6 millionth Holden (a VX Commodore SS) in June 2001, and the 7 millionth Holden (a VE Commodore) in August 2008. Total number of vehicles built at all plants in Australia by Holden (including export models) from 1948-2017 is 7,687,675. Production ended October 20, 2017. Final vehicle made at Elizabeth and final Australian-built Holden was a VFII Commodore Redline with a manual transmission.[https://www.carsales.com.au/editorial/details/holdens-manufacturing-closure-by-the-numbers-109466/] Epicurean Food Group bought the site in 2023 and is using it as a farm to grow mushrooms.

Cars produced before its final year before closure included the [[w:Pontiac GTO#Fifth generation|Pontiac GTO]] (2004-2006), [[w:Vauxhall Monaro|Vauxhall Monaro]], [[w:Holden Monaro|Holden Monaro]], [[w:Pontiac G8|Pontiac G8]] (2008-2009), [[w:Holden Gemini#Second generation|Holden Gemini (RB)]], [[w:Chevrolet Cruze#First generation (J300; 2008)|Holden Cruze (JH)]], [[w:Holden Torana|Holden Torana]], [[w:Opel Vectra#Vectra B (1995–2002)|Holden Vectra (JS)]], [[w:Statesman (automobile)|Statesman brand WB]], [[w:Holden WB|Holden WB]] Ute &amp; One-Tonner, [[w:Holden Adventra|Holden Adventra]], [[w:Holden Crewman|Holden Crewman]], [[w:Chevrolet Lumina#Holden-based models|Chevrolet Lumina]], [[w:Chevrolet Caprice#Fifth generation (1999–2006)|Chevrolet Caprice]], [[w:Chevrolet Cruze#First generation (J300; 2008)|Chevrolet Cruze]] 5-door, [[w:Chevrolet Omega|Chevrolet Omega]] B &amp; C, [[w:Buick Royaum|Buick Royaum]], [[w:Daewoo Statesman|Daewoo Statesman]], and [[w:Daewoo Veritas|Daewoo Veritas]]. Also, [[w:United Australian Automobile Industries#Toyota Lexcen|Toyota Lexcen]].  

|- 

|&amp;nbsp;||Holden Fishermans Bend Plant (Port Melbourne)||[[w:Port Melbourne|Port Melbourne]], [[w:Victoria, Australia|Victoria]]||[[w:Australia|Australia]]||[[w:GM High Feature engine|Holden Alloytec V6 engine]]&lt;br /&gt;[[w:Buick V6 engine#3800 V6|Buick V6]]&lt;br /&gt;[[w:GM Family II engine|GM Family II I4 engine]]&lt;br /&gt;[[w:Holden V8 engine]]&lt;br /&gt;[[w:Holden straight-six motor#Starfire|Holden Starfire I4]]&lt;br /&gt;[[w:Holden straight-six motor|Holden straight-six motor]]&lt;br /&gt;Manual transmissions&lt;br /&gt;[[w:Holden Salisbury differential|Holden Banjo/Salisbury differentials]]&lt;br /&gt;Axles&lt;br /&gt;Stampings&lt;br /&gt;Components&lt;br /&gt;Foundry ||1936||2016||Headquarters of GM Holden Ltd. &lt;br /&gt; Holden's Engine Company/Holden Engine Operations.&lt;br /&gt;  

Used to build vehicles as well including the [[w:Holden 48-215|Holden 48-215]] &amp; [[w:Holden FJ|Holden FJ]]. Vehicle assembly ended in 1956 and was moved to Dandenong. &lt;br /&gt; Versions of the Alloytec/High Feature V6 were also supplied to [[w:Saab Automobile|Saab]] &amp; [[w:Alfa Romeo|Alfa Romeo]] from this plant. &lt;br /&gt; 

Sold to the Victorian state Government in 2016.  

|- 

|B||Holden Fortitude Valley Plant||[[w:Fortitude Valley|Fortitude Valley]], [[w:Queensland|Queensland]]||[[w:Australia|Australia]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt;[[w:Oakland (automobile)|Oakland]]&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]]&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:Cadillac|Cadillac]]&lt;br /&gt;[[w:GMC (automobile)|GMC]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford]]&lt;br /&gt;[[w:Holden 48-215|Holden 48-215]]&lt;br /&gt;[[w:Holden FJ|Holden FJ]]&lt;br /&gt;[[w:Holden FE|Holden FE]]&lt;br /&gt;[[w:Holden FC|Holden FC]]&lt;br /&gt;[[w:Holden FB|Holden FB]]&lt;br /&gt;[[w:Holden EK|Holden EK]]&lt;br /&gt;[[w:Holden EJ|Holden EJ]]&lt;br /&gt;[[w:Holden EH|Holden EH]]&lt;br /&gt;||1927||1965||[[w:Holden|Holden]] plant. Built by GM Australia before it merged with Holden's Motor Body Builders Ltd. Plant was closed from 1931 until 1934. Fortitude Valley combined bodies made in Woodville with CKD chassis assembled in Melbourne. Replaced by Acacia Ridge plant.  

|- 

|&amp;nbsp;||Holden Marrickville Plant||[[w:Marrickville, New South Wales|Marrickville, New South Wales]]||[[w:Australia|Australia]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt;[[w:Oakland (automobile)|Oakland]]&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]]&lt;br /&gt;[[w:Marquette (automobile)#Buick brand|Marquette]]&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:Cadillac|Cadillac]]&lt;br /&gt;[[w:GMC (automobile)|GMC]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford]]||1926||1940||[[w:Holden|Holden]] plant. Built by GM Australia before it merged with Holden's Motor Body Builders Ltd. Plant was closed from 1931 until 1934. Marrickville combined bodies made in Woodville with CKD chassis assembled in Melbourne. Building sold. Replaced by Pagewood plant.  

|- 

|&amp;nbsp;||Holden Melbourne Plant (City Road)||[[w:Melbourne|Melbourne]], [[w:Victoria, Australia|Victoria]]||[[w:Australia|Australia]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt;[[w:Oakland (automobile)|Oakland]]&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]]&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:Cadillac|Cadillac]]&lt;br /&gt;[[w:GMC (automobile)|GMC]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]]||1926||1936||[[w:Holden|Holden]] plant. Acquired by GM Australia before it merged with Holden's Motor Body Builders Ltd. Melbourne combined bodies made in Woodville with CKD chassis assembled in Melbourne. Building sold. Replaced by Fishermans Bend plant.  

|- 

|P,&lt;br&gt; L6||Holden Mosman Park Plant||[[w:Mosman Park, Western Australia|Mosman Park (formerly Cottesloe Beach)]], [[w:Western Australia|Western Australia]]||[[w:Australia|Australia]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt;[[w:Oakland (automobile)|Oakland]]&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]]&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:Cadillac|Cadillac]]&lt;br /&gt;[[w:GMC (automobile)|GMC]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford]]&lt;br /&gt;[[w:Holden|Holden]]&lt;br /&gt;||1926||1972||[[w:Holden|Holden]] plant. Built by GM Australia before it merged with Holden's Motor Body Builders Ltd. Plant was closed from 1932 until 1935. Also produced military vehicles &amp; equipment during WWII. Before WWII, Mosman Park combined bodies made in Woodville with CKD chassis assembled in Melbourne. After WWII, Mosman Park assembled CKD chassis imported from the US, Canada, &amp; the UK and combined them with bodies made in Woodville. Once Holden brand cars started to be made in 1948, body and chassis components came from Woodville &amp; powertrain came from Fishermans Bend and final assembly was done in Mosman Park. Plant was closed down in 1972. Demolished in the early 1990s. 

|- 

|S,&lt;br&gt; H5, H6, H7,&lt;br&gt; H8, H9||Holden Pagewood Plant||[[w:Pagewood, New South Wales|Pagewood, New South Wales]]||[[w:Australia|Australia]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford]]&lt;br /&gt;[[w:Holden 48-215|Holden 48-215]]&lt;br /&gt;[[w:Holden FJ|Holden FJ]]&lt;br /&gt;[[w:Holden FE|Holden FE]]&lt;br /&gt;[[w:Holden FC|Holden FC]]&lt;br /&gt;[[w:Holden FB|Holden FB]]&lt;br /&gt;[[w:Holden EK|Holden EK]]&lt;br /&gt;[[w:Holden EJ|Holden EJ]]&lt;br /&gt;[[w:Holden EH|Holden EH]]&lt;br /&gt;[[w:Holden HD|Holden HD]]&lt;br /&gt;[[w:Holden HR|Holden HR]]&lt;br /&gt;[[w:Holden HK|Holden HK]]&lt;br /&gt;[[w:Holden HT|Holden HT]]&lt;br /&gt;[[w:Holden HG|Holden HG]]&lt;br /&gt;[[w:Holden Monaro|Holden Monaro]]&lt;br /&gt;[[w:Holden HQ|Holden HQ]]&lt;br /&gt;[[w:Holden HJ|Holden HJ]]&lt;br /&gt;[[w:Holden HX|Holden HX]]&lt;br /&gt;[[w:Holden HZ|Holden HZ]]&lt;br /&gt;[[w:Holden Torana|Holden Torana]]&lt;br /&gt; [[w:Holden Commodore (VB)|Holden Commodore (VB)]]&lt;br /&gt;[[w:Statesman (automobile)|Statesman brand HQ-HZ]]&lt;br /&gt;Body making||1940||1980||[[w:Holden|Holden]] plant. Also produced military equipment during WWII. Before WWII, Pagewood combined bodies made in Woodville with CKD chassis assembled in Melbourne. After WWII, Pagewood assembled CKD chassis imported from the US, Canada, &amp; the UK and combined them with bodies made in Woodville. Also made Frigidaire appliances. Built the 3 millionth Holden (an HQ) in June 1974. Vehicle production ended in 1980 while plant closedown operations extended into 1981.  

|- 

|&amp;nbsp;||[[w:Holden Woodville Plant|Holden Woodville Plant]]||[[w:Woodville, South Australia|Woodville, South Australia]]||[[w:Australia|Australia]]||[[w:Holden|Holden]]:&lt;br /&gt;Stamping&lt;br /&gt;Body making&lt;br /&gt;Paint shop&lt;br /&gt;Body Hardware&lt;br /&gt;Trim&lt;br /&gt;Tool &amp; Die&lt;br /&gt;[[w:Tri-Matic|Tri-Matic]] automatic transmission||1923||1965||[[w:Holden|Holden]] plant. Built before Holden was taken over by GM. Built car bodies for many brands of cars including GM brands (Chevrolet, Pontiac, Oakland, Oldsmobile, Marquette, Buick, LaSalle, Cadillac, GMC, Vauxhall, &amp; Bedford) and non-GM brands (Chrysler, DeSoto, Dodge, Plymouth, Willys, Hudson, Nash, Studebaker, Austin, Morris, Rover, Standard, Fiat, &amp; others). (Holden Motor Body Works.) Also produced military equipment during WWII. Once Holden brand cars started to be made in 1948, body and chassis components were made in Woodville. Also produced replacement parts for discontinued models. Most operations transferred to Elizabeth between 1959 &amp; 1965. Built the Tri-Matic automatic transmission from 1969-1987. Plant sold in 1984. Tri-Matic production area was leased back until production ended. Other companies continued production of spare parts.  

|- 

|V||[[w:IBC Vehicles|IBC Vehicles Ltd.]]/&lt;br&gt;[[w:GMM Luton|GMM Luton]]&lt;ref&gt;{{cite web |title=Company Profile |publisher=Vauxhall |url=http://media.gm.com/gb/vauxhall/en/company/c_company-profile/index.html |access-date=2009-06-29 |archive-url=https://archive.today/20090629105853/http://media.gm.com/gb/vauxhall/en/company/c_company-profile/index.html |archive-date=2009-06-29}}&lt;/ref&gt;||[[w:Luton|Luton]], [[w:Bedfordshire|Bedfordshire]]||[[w:United Kingdom|United Kingdom]]||[[w:Bedford CF#CF2|Bedford CF2]]&lt;br /&gt;[[w:Isuzu Fargo#Bedford Midi / Vauxhall Midi|Bedford/Vauxhall/GME/Isuzu Midi/&lt;br&gt;Bedford Seta/Vauxhall Albany]]&lt;br /&gt;[[w:Suzuki Carry#Bedford Rascal|Bedford/Vauxhall/GME Rascal]]&lt;br /&gt;[[w:Suzuki Carry#Export models|Suzuki Super Carry]]&lt;br /&gt;[[w:Isuzu MU#First generation (UCS55/UCS69GW; 1989–1998)|Opel/Vauxhall Frontera A]]&lt;br /&gt;[[w:Isuzu MU#Second generation (UER25FW, UES25FW, UES73FW; 1998–2004)|Opel/Vauxhall Frontera B]]&lt;br /&gt;[[w:Holden Frontera#First generation (UCS55/UCS69GW; 1989–1998)|Holden Frontera (UT)]]&lt;br /&gt;[[w:Renault Trafic#Second generation (X83; 2001)|Opel/Vauxhall Vivaro]] A (low roof versions only)&lt;br /&gt;[[w:Renault Trafic#Third generation (X82; 2014)|Opel/Vauxhall Vivaro]] B (low roof versions only)&lt;br /&gt;[[w:Renault Trafic#Second generation (X83; 2001)|Renault Trafic (X83)]] (low roof versions only)&lt;br /&gt;[[w:Renault Trafic#Second generation (X83; 2001)|Nissan Primastar (X83)]] (low roof versions only)||1950 (as AA Block of Luton plant)&lt;br&gt;&lt;br&gt;1984 (as Bedford Luton Van Plant)||2017|| [[w:Vauxhall Motors|Vauxhall plant]]. Began as the Bedford van plant when Bedford vans were moved out of the Luton passenger car plant and into a separate, nearby plant (AA Block [body assembly and paint] &amp;&lt;br&gt; K Block [trim and final assembly] of the Luton complex) connected by a bridge so that components for the CF van made in the car plant could be easily transferred to the van plant. Was part of the Bedford Commercial Vehicles Division of the GM Overseas Commercial Vehicles Corp. CF2 production ended in July 1987. Built the Isuzu-designed Midi from December 20, 1984 through May 23, 1996 though the Midi was still available through the 1997 model year. An upscale, 7-psgr. variant of the Midi called the Vauxhall Albany was built for 1991 only. Built the Suzuki-designed Rascal from February 1986 through July 3, 1993. Also built the Rascal's Suzuki counterpart, the Super Carry, for the UK &amp; other European markets. Became a joint venture with [[w:Isuzu|Isuzu]] called IBC Vehicles Ltd., which was incorporated on January 20, 1987. Production under IBC Vehicles began in October 1987 after the plant was reorganized and staff was retrained. GM owned 60% &amp; Isuzu held 40%. The Bedford brand was discontinued and replaced by the Vauxhall brand on light commercial vehicles as of June 1, 1990. GM bought Isuzu's stake in IBC Vehicles back in 1998 &amp; the operation was again a subsidiary of GM. It was then renamed GMM (GM Manufacturing) Luton. Sold to [[w:PSA Group|PSA Group]] in 2017. Part of [[w:Stellantis|Stellantis]] since 2021. Production ended March 28, 2025. Last vehicle produced was a Vauxhall Vivaro. Site has been sold for redevelopment into an industrial park.

|- 

|&amp;nbsp;||[[w:IDA-Opel|IDA-Opel]]||[[w:Kikinda|Kikinda]], [[w:Socialist Republic of Serbia|Socialist Republic of Serbia]]||[[w:Yugoslavia|Yugoslavia]]||[[w:Opel Ascona#Ascona C (1981–1988)|Opel Ascona]] C&lt;br /&gt;[[w:Opel Corsa#Corsa A (S83; 1982)|Opel Corsa]] A&lt;br /&gt;[[w:Opel Kadett|Opel Kadett]] D &amp; E&lt;br /&gt;[[w:Opel Kikinda#Senator A (1978–1986)|Opel Kikinda]] (Senator A)&lt;br /&gt;[[w:Opel Omega#Omega A (1986–1994)|Opel Omega]] A&lt;br /&gt;[[w:Opel Rekord Series E|Opel Rekord]] E&lt;br /&gt;[[w:Opel Vectra#Vectra A (1988–1995)|Opel Vectra]] A&lt;br /&gt;Iron castings, brake, and axle components||1977||1992|| [[w:Adam Opel AG|Opel affiliate]]. A joint venture owned 49% by GM &amp; 51% by Kikinda Iron Foundry. IDA = Industrija Delova Automobila or Industry of Automobile Parts. The operation exported iron castings, brake, and axle components to GM/Opel, thus allowing partially built Opels to be imported into Yugoslavia and not be counted as imports. Ended by the wars of the breakup of Yugoslavia and imposition of sanctions on Yugoslavia in 1992. The plant was later restructured as the Livnica Kikinda metal foundry, which was taken over by Slovenia's Cimos in 2004 and manufactures auto parts for various European manufacturers including Opel.   

|- 

|&amp;nbsp;||Indianapolis Metal Center||[[w:Indianapolis|Indianapolis]], [[w:Indiana|Indiana]]||United States||Metal stampings for trucks||1930||2011||Located at 340 S. White River Parkway W. Drive. Stamping plant. Acquired from the former Martin-Parry Corporation in 1930. Became a Chevrolet plant making truck bodies. Became part of GM Truck &amp; Bus Group in 1982 and in early 1992, became part of NATP (North American Truck Platforms) and later transferred to CLCD (Cadillac/Luxury Car Division) before joining the Metal Fabrication Division in 1994. Closed in June 2011. Demolished in 2014-2015. 

|- 

|&amp;nbsp;||Inland Fisher Guide Plant (Columbus, Ohio)||[[w:Columbus, Ohio|Columbus, Ohio]]||United States||Door Panel Assemblies &amp; Small Components||1946||1999||Located at 200 Georgesville Road. Originally opened as a plant for the Ternstedt Division of General Motors. Then, Fisher Hardware Fabrication when Ternstedt merged back into Fisher Body in 1969. Fisher became Fisher Guide in 1984 and Inland Fisher Guide in 1989. In 1995, Inland Fisher Guide became the Delphi Interior and Lighting Systems division of GM's [[w:Delphi Automotive Systems|Delphi Automotive Systems]] subsidiary. Spun off with [[w:Delphi Automotive Systems|Delphi Automotive Systems]] in 1999. Closed by Delphi in 2007. 

|- 

|&amp;nbsp;||Inland Fisher Guide Dayton Plant||[[w:Dayton, Ohio|Dayton]], [[w:Ohio|Ohio]]||United States||Engine Mounts&lt;br /&gt;Transmission Mounts&lt;br /&gt;Strut Mounts&lt;br /&gt;Steering Wheels&lt;br /&gt;Liteflex Springs&lt;br /&gt;Brake Linings&lt;br /&gt;Brake Hose&lt;br /&gt;Brake Pads&lt;br /&gt;Ball Joints&lt;br /&gt;Ice Cube Trays ||1921||1999||Located at 2701 Home Avenue (originally Home Road). The first factory building was built in 1910 by the Wright Company and made airplanes and components. The 2nd factory building was built in 1911 &amp; made airplane engines. Aircraft production ceased in 1916. 13 different types of planes had been produced. In Feb. 1917, the plants were sold to the Darling Motor Co. but they went bankrupt shortly thereafter. The Dayton-Wright Company bought the site from Darling Motor on March 22, 1917 and made aircraft parts at the site for its Moraine assembly plant from 1918 to 1919. Dayton-Wright Company was bought by GM in 1919 &amp; it was initially run as a GM subsidiary. In 1923, the aircraft part of the business was sold to Consolidated Aircraft Co. &amp; this site switched from aviation production to automotive production. Inland Manufacturing Division (originally Inland Mfg. Company) of GM was formed on January 6, 1923 at this site, initially to make steering wheels. Merged with Fisher Guide to became Inland Fisher Guide in 1989. In 1995, Inland Fisher Guide became the Delphi Interior and Lighting Systems division of GM's [[w:Delphi Automotive Systems|Delphi Automotive Systems]] subsidiary. Spun off with [[w:Delphi Automotive Systems|Delphi Automotive Systems]] in 1999. Delphi closed it in 2008. The 2 original Wright Brothers' buildings were left standing and became part of Dayton Aviation Heritage National Historical Park in 2009 but the rest was demolished around 2014. The Wright Brothers factory buildings were damaged by fire in March 2023.

|- 

|&amp;nbsp;||Inland Fisher Guide Plant (Detroit - Fort St.)||[[w:Detroit, Michigan|Detroit, Michigan]]||United States||Door hinges and interior parts||1920||1989||Located at 6307 W. Fort St. &amp; Livernois St. Was Ternstedt's headquarters until 1962. Originally opened by Ternstedt Manufacturing Co., which was taken over by Fisher Body Co. in 1920. Became part of GM when GM took over Fisher Body in 1926. Ternstedt became a separate division of GM in 1948 before merging back in to Fisher Body in 1969. Was a plant for the Ternstedt Division (Plant# 16) of General Motors. Then, Fisher Hardware Fabrication. Fisher became Fisher Guide in 1984 and Inland Fisher Guide in 1989. Is now Evans Distribution Systems.  

|- 

|&amp;nbsp;||Inland Fisher Guide Plant (Elyria, Ohio)||[[w:Elyria, Ohio|Elyria, Ohio]]||United States||Car seats||1947||1990||Located at 1400 Lowell St. Originally opened as a plant for the Ternstedt Division of General Motors. Then, Fisher Hardware Fabrication when Ternstedt merged back into Fisher Body in 1969. Fisher became Fisher Guide in 1984 and Inland Fisher Guide in 1989.  

|- 

|&amp;nbsp;||Inland Fisher Guide Plant (Euclid, Ohio)||[[w:Euclid, Ohio|Euclid, Ohio]]||United States||Vehicle Bodies until 1970&lt;br /&gt;Then, trim fabrication, seat covers &amp; backs, upholstery, door panels, sunvisors, &amp; other interior parts.&lt;br /&gt;Also made seats &amp; cushions for Sea Ray Boats||1947||1993||Located at 20001 Euclid Ave. Originally built in 1943. Bought by GM in 1947 from Cleveland Pneumatic Aerol Co., which made rocket shells and aircraft landing gear there during WWII. Was a Fisher Body plant making bodies for Chevrolet, Pontiac, Oldsmobile, &amp; Buick until 1970. Then became a Fisher Trim Fabrication plant. Fisher became Fisher Guide in 1984 and Inland Fisher Guide in 1989. Closed in 1993. Site currently in use by an industrial supply store (HGR) and indoor sports facilities (The Sports Plant).  

|- 

|&amp;nbsp;||[[w:Automotive industry in Flint, Michigan#Coldwater Road Plant|Inland Fisher Guide Plant (Flint - Coldwater Road)]]||[[w:Genesee Township, Michigan|Genesee Township, Michigan]]||United States||Window regulators, door hinges, door modules and seat adjusters||1953||1996||Located at 1245 East Coldwater Road. Originally opened as a plant for the Ternstedt Division of General Motors. Then, Fisher Hardware Fabrication when Ternstedt merged back into Fisher Body in 1969. Fisher became Fisher Guide in 1984 and Inland Fisher Guide in 1989. In 1995, Inland Fisher Guide became the Delphi Interior and Lighting Systems division of GM's [[w:Delphi Automotive Systems|Delphi Automotive Systems]] subsidiary. Sold to Peregrine Inc. in 1996, which continued making window regulators and door hinges and modules. Closed by Peregrine in 1998. A GM subsidiary called REALM bought the property in 1999 and GM used the administration building until 2000. Demolished by 2001. Site now used by Deployment Strategies Group LLC for container storage. 

|- 

|&amp;nbsp;||Inland Fisher Guide Plant (Grand Rapids, Michigan)||[[w:Walker, Michigan|Walker, Michigan]]||United States||Interior trim||1942||1998||Located at 2150 Alpine Avenue NW. Built by Haskelite Manufacturing Corporation to make wooden gliders for use in WWII. Bought by GM in the early 1950's. Built fuselages for [[w:F-84F Thunderstreak|F-84F Thunderstreak]] fighter jets. Fisher became Fisher Guide in 1984 and Inland Fisher Guide in 1989. In 1995, Inland Fisher Guide became the Delphi Interior and Lighting Systems division of GM's [[w:Delphi Automotive Systems|Delphi Automotive Systems]] subsidiary. Became part of Delphi in 1995. Sold by GM to [[w:Lear Corp.|Lear Corp.]] in 1998. Closed by Lear in 2005. Now called Avastar Park, a multi-tenant industrial site.  

|- 

|&amp;nbsp;||Inland Fisher Guide Plant (Livonia, Michigan)||[[w:Livonia, Michigan|Livonia, Michigan]]||United States||Seat Cushions, Seat Pads, Seat Backs, Door Panel Trim||1954||1995||Built on the site of the former Detroit Transmission Division plant that burned down in 1953. Located at 28400 Plymouth Road. Fisher became Fisher Guide in 1984 and Inland Fisher Guide in 1989. In 1995, Inland Fisher Guide became the Delphi Interior and Lighting Systems division of GM's [[w:Delphi Automotive Systems|Delphi Automotive Systems]] subsidiary. Closed in 1995. Sold to Peregrine Inc. in 1996, which continued making interior trim parts. Peregrine then closed the plant in 1998. Now the Plymouth Road Technical Center, a multi-tenant site for industrial, warehousing, and logistics purposes. 

|- 

|&amp;nbsp;||Inland Fisher Guide Plant (Syracuse)||[[w:Salina, New York|Salina, New York]]||United States||Metal auto parts (die casting, stamping, machining, painting, plating), Plastic trim parts - exterior and interior (injection molding)||1952||1993||Located at One General Motors Drive (address sometimes listed as 1000 Town Line Road). Plastic operations were added in the early 1960's. Metal operations were subsequently reduced and ultimately replaced by the plastic operations by the early 1970's. Fisher became Fisher Guide in 1984 and Inland Fisher Guide in 1989. Closed December 1993. Property is now Salina Industrial Powerpark, a multi-tenant industrial park.  

|- 

|&amp;nbsp;||Inland Fisher Guide Plant (Tecumseh, Michigan)||[[w:Tecumseh, Michigan|Tecumseh, Michigan]]||United States||Seat Pads &amp; Backs||1966||1988||Located at 5550 Occidental Highway. Fisher became Fisher Guide in 1984. Now occupied by Uniloy Inc., a plastics company. 

|- 

|&amp;nbsp;||[[w:Inland Fisher Guide Plant (New Jersey)|Inland Fisher Guide Plant (Trenton)]]||[[w:West Trenton, New Jersey|West Trenton]], [[w:Ewing Township, New Jersey|Ewing Township]], [[w:New Jersey|New Jersey]]||United States||Door handles&lt;br /&gt;Hinges&lt;br /&gt;Door locks&lt;br /&gt;Seat adjusters&lt;br /&gt;Exterior body moldings and painted components||1938||1998||Located at 1445 Parkway Ave. Built 7,546 [[w:TBM Avenger|TBM Avenger]] torpedo bombers during WWII under license from Grumman as part of GM's Eastern Aircraft Division. In 1961, the facility became the first commercial user in the United States to use a programmable industrial robot to replace human workers. Brief article about the plant's closing and displaced workers. 1993 Plant closing date was later delayed until Summer of 1998 : [https://query.nytimes.com/gst/fullpage.html?res=9E0CEEDB1E3EF937A35751C1A964958260] Originally part of the [[w:Flint, Michigan auto industry#Ternstedt Division|Ternstedt Division]] of Fisher Body, then the Ternstedt Division of GM in 1948 before Ternstedt merged back in to Fisher Body in 1969. Then, Fisher Hardware Fabrication. Fisher became Fisher Guide in 1984 and Inland Fisher Guide in 1989. In 1995, Inland Fisher Guide became the Delphi Interior and Lighting Systems division of GM's [[w:Delphi Automotive Systems|Delphi Automotive Systems]] subsidiary. Closed in 1998. Plant was subsequently demolished. Site redeveloped into Ewing Town Center, a mixed retail and residential complex. 

|- 

|&amp;nbsp;||Inland Fisher Guide Plant (Vandalia, Ohio)||[[w:Vandalia, Ohio|Vandalia, Ohio]]||United States||Door Panel Assemblies&lt;br /&gt;Seat Pads&lt;br /&gt;Instrument Panels||1941||1999||Located at 250 Northwoods Boulevard. Originally a GM Aeroproducts division facility making aircraft propellers, Aeroproducts division became part of GM's Allison division in 1952, site was absorbed by GM's Inland division in 1961 after propeller production moved to Allison's Indianapolis operation in 1960, merged into Inland Fisher Guide division in 1991, became part of GM's [[w:Delphi Automotive Systems|Delphi Automotive Systems]] subsidiary in 1995 and transferred to Delphi Chassis Division. Spun off with Delphi in 1999. Transferred to Delphi Thermal Division in 2007. Sold in 2015 to [[w:Mahle GmbH|Mahle GmbH]]. Mahle transferred operations to its Behr plant in Dayton and closed the Vandalia plant by 2016. Mahle sold the property in 2017.

|- 

|&amp;nbsp;||General Motors International A/S||[[w:Copenhagen|Copenhagen]]||[[w:Denmark|Denmark]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Oakland (automobile)|Oakland]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]]&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:Opel|Opel]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]]||1924||1974||GM's 1st European assembly plant &amp; 1st assembly plant outside North America. First vehicle off the line was a Chevrolet utility truck on January 7, 1924. Pontiac assembly began July 24, 1926. Oakland, Oldsmobile, &amp; Buick assembly began in 1929. In the 1960's, the Chevy Chevelle &amp; Buick Skylark were assembled along with most Opel &amp; Vauxhall models. Station wagon-based vans were assembled as was the Opel 1500, based on the 1200. Production ended in Oct. 1974. Over 550,000 units had been produced.  

|- 

|&amp;nbsp;||[[w:General Motors do Brasil|Ipiranga]]||[[w:Ipiranga (district of São Paulo)|Ipiranga]], [[w:São Paulo (state)|São Paulo (state)]]||[[w:Brazil|Brazil]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Oakland (automobile)|Oakland]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]]&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:Cadillac|Cadillac]]||1925||1930||GM's 1st Brazilian assembly plant. Replaced by Sao Caetano do Sul plant.  

|-

|&amp;nbsp;||[[w:Pars Khodro|General Motors Iran]]||[[w:Tehran|Tehran]]||[[w:Imperial State of Iran|Imperial State of Iran]]||[[w:Opel Commodore#Foreign assembly|Chevrolet Iran 2500/2800/Royale]]&lt;br /&gt;[[w:Chevrolet Nova#Fourth generation (1975–1979)|Chevrolet Iran (Nova)]]&lt;br /&gt;[[w:Buick Skylark#Buick Skylarks in Iran|Buick Iran (Skylark)]]&lt;br /&gt;[[w:Cadillac Seville#First generation (1976–1979)|Cadillac Iran (Seville)]]&lt;br /&gt;[[w:Chevrolet C/K (third generation)|Chevrolet C/K pickup]] ||1974||1987||When the Shah ruled Iran, GM established a joint venture in Iran called GM Iran. GM held 45% while Pars Khodro held the other 55%. Production began on January 15, 1974 of the Opel Commodore-based Chevrolet Iran 2500/2800/Royale. By 1977, this was replaced by the American Chevrolet Nova, Buick Skylark, &amp; Cadillac Seville. Chevy pickups followed. Once the Shah was overthrown in the 1979 Revolution and Iran was taken over by fanatics, GM abandoned the factory &amp; Iran. The company became Pars Khodro and the local management changed. Production of GM models continued sporadically until 1987 when it finally ended. 

|- 

|J (1953-2009)&lt;br /&gt;&lt;br /&gt;21 (1928-1952 [[w:Chevrolet|Chevrolet]])||[[w:Janesville Assembly Plant|Janesville Assembly Plant]]||[[w:Janesville, Wisconsin|Janesville, Wisconsin]]||United States||[[w:Chevrolet K5 Blazer|Chevrolet K5 Blazer]] (1992-1994)&lt;br /&gt; [[w:Chevrolet Tahoe|Chevrolet Tahoe]] (1995-2009) &lt;br /&gt;[[w:Chevrolet Suburban|Chevrolet Suburban]] (1947-1966, 1992-2009)&lt;br /&gt; [[w:Chevrolet Tiltmaster|Chevrolet Tiltmaster/W-Series (Gas-powered)]] (1994-2009)&lt;br /&gt; [[w:GMC Forward|GMC Forward/W-Series (Gas-powered)]] (1994-2009)&lt;br /&gt; [[w:Isuzu N-Series|Isuzu N-Series (Gas-powered)]] (1994-2009)&lt;br /&gt;[[w:Chevrolet Tahoe|GMC Yukon]] (1992-2009)&lt;br /&gt; [[w:Chevrolet Tahoe#Second generation (2000)|GMC Yukon Denali (GMT800)]] (2001-2006)&lt;br /&gt; [[w:Chevrolet Tahoe#Third generation (2007)|GMC Yukon Denali (GMT900)]] (2007-2009) &lt;br /&gt;[[w:GMC Suburban|GMC Suburban]] (1992-1999)&lt;br /&gt;[[w:GMC Yukon XL|GMC Yukon XL]] (2000-2009) &lt;br /&gt; [[w:Chevrolet Suburban#Ninth generation (2000)|GMC Yukon XL Denali (GMT800)]] (2001-2006) &lt;br /&gt; [[w:Chevrolet Suburban#Tenth generation (2007)|GMC Yukon XL Denali (GMT900)]] (2007-2009)||1919||2009||Located at 1000 General Motors Dr. Was the oldest active GM assembly plant at time of its closure in 2009; largest under one roof in the U.S. 

Originally built [[w:Samson Tractor|Samson tractors]] from 1919-1922. Also made [[w:Samson Tractor#Trucks and a car|Samson trucks]] from 1920-1922. On October 1, 1922, the Janesville plant was transferred to Chevrolet. Started producing Chevrolets on Feb. 14, 1923. Shortly thereafter, a neighboring Fisher Body plant was added. Plant closed from September 1932 - late 1933. During World War II, both the Chevy &amp; Fisher Body sides of the plant were controlled by Oldsmobile and made artillery shells. Was part of the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were gradually transferred to the GM Assembly Division which replaced the BOP Assembly Division in 1965. Janesville Assembly joined the GM Assembly Division in 1968. On April 21, 1967, the 100 millionth GM vehicle built in the US, a blue, two-door Chevrolet Caprice, was produced at the Janesville plant. Full-size cars ended production in 1982 and were replaced by the compact J-cars like the Cavalier. Last passenger car built was the 1991 Chevy Cavalier. Only SUVs and trucks were subsequently built. SUV production ended Dec. 23, 2008. Last vehicle produced was a black 2009 Chevy Tahoe. Medium-duty truck production ended on April 23, 2009, marking the end of vehicle production at Janesville. Officially, the plant was placed on &quot;standby&quot; status but production never restarted and the 2015 GM-UAW contract allowed Janesville to be closed permanently. Demolished from 2018-2019.&lt;br /&gt; 

Past models: [[w:Chevrolet Superior|Chevrolet Superior]], [[w:Chevrolet Series AA Capitol|Chevrolet Series AA Capitol]], [[w:Chevrolet Series AB National|Chevrolet Series AB National]], [[w:Chevrolet Series AC International|Chevrolet Series AC International]], [[w:Chevrolet Series AD Universal|Chevrolet Series AD Universal]], [[w:Chevrolet Series AE Independence|Chevrolet Series AE Independence]], [[w:Chevrolet Series BA Confederate|Chevrolet Series BA Confederate]], [[w:Chevrolet Standard Six|Chevrolet Standard Six]], [[w:Chevrolet Series CA Eagle / Master|Chevrolet Series CA Eagle / Master]], [[w:Chevrolet Master|Chevrolet Master]], [[w:Chevrolet Deluxe|Chevrolet Deluxe]], [[w:Chevrolet Stylemaster|Chevrolet Stylemaster]], [[w:Chevrolet Fleetmaster|Chevrolet Fleetmaster]], [[w:Chevrolet 150|Chevrolet 150]] (1953-1957), [[w:Chevrolet 210|Chevrolet 210]] (1953-1957), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1950-1970), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1958-1972), [[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-1982), [[w:Chevrolet Cavalier|Chevrolet Cavalier]] (1982-1991), [[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958), [[w:Chevrolet El Camino#First generation (1959–1960)|Chevrolet El Camino]] (1959-1960), [[w:Chevrolet Impala|Chevrolet Impala]] (1958-1982), [[w:Chevrolet Nomad|Chevrolet Nomad]] (1955-1957), [[w:Buick Skyhawk#Second generation (1982–1989)|Buick Skyhawk]] (1988-1989), [[w:Cadillac Cimarron|Cadillac Cimarron]] (1982-1988), [[w:Chevrolet AK Series|Chevrolet AK Series]], [[w:Chevrolet Advance Design|Chevrolet Advance Design]] (1947-1955), [[w:Chevrolet Task Force|Chevrolet Task Force]] (1955-1959), [[w:Chevrolet C/K|Chevrolet C/K]] (1960-1986), [[w:Chevrolet C/K (third generation)#R/V-Series (1987–1991)|Chevrolet R/V]] (1987-1989), [[w:Chevrolet C/K (fourth generation)|Chevrolet C/K crew cab (GMT400)]] (1992-1994), [[w:Chevrolet C/K (fourth generation)#C3500HD (1991–2002)|Chevrolet C3500HD]] (1991-1998), [[w:Chevrolet Kodiak#Second generation (1990–2002)|Chevrolet Kodiak (GMT530)]] (1990-2002), [[w:Chevrolet/GMC B series#Third generation (1993–2003)|Chevrolet B-series]] (1993-02), [[w:Isuzu Forward|Chevrolet T-Series]] (1997-2002), [[w:Chevrolet C/K (second generation)|GMC C/K (Action Line)]] (1967-1972), [[w:Chevrolet C/K (third generation)|GMC C/K (Rounded Line)]] (1973-1986), [[w:Chevrolet C/K (third generation)#R/V-Series (1987–1991)|GMC R/V]] (1987-1989), [[w:Chevrolet C/K (fourth generation)|GMC Sierra crew cab (GMT400)]] (1992-1994), [[w:Chevrolet C/K (fourth generation)#C3500HD (1991–2002)|GMC Sierra C3500HD]] (1991-1998), [[w:Chevrolet Kodiak#Second generation (1990–2002)|GMC TopKick (GMT530)]] (1990-02), [[w:Chevrolet/GMC B series#Third generation (1993–2003)|GMC B-series]] (1993-2002), [[w:GMC T-Series|GMC T-Series]] (1997-2002), [[w:Isuzu F-Series|Isuzu F-Series]] (1997-2002)

|- 

|&amp;nbsp;||Kalamazoo Metal Center||[[w:Kalamazoo, Michigan|Kalamazoo, Michigan]]||United States||Stamped Body panels ||1965||1999|| Located at 5200 East Cork Street. Metal stamping plant. Started out as a Fisher Body plant. Now Midlink Business Park. 

|- 

|K||[[w:GM Korea|GM Korea]]||[[w:Gunsan|Kunsan]], [[w:Jeolla Province|Jeolla]]||[[w:South Korea|South Korea]]||[[w:Chevrolet Cruze|Chevrolet Cruze]]&lt;br /&gt;[[w:Holden Cruze#Australia|Holden Cruze (JG sedan/JH wagon)]]&lt;br /&gt;[[w:Holden Astra#Seventh generation (BK, BL; 2016)|Holden Astra Sedan (BL)]] (4-door)&lt;br /&gt;[[w:Chevrolet Orlando|Chevrolet Orlando]]&lt;br /&gt;[[w:GM Family Z engine|Family Z diesel engine]]||1997||2018||Past models: [[w:Daewoo Lacetti|Daewoo Lacetti]], [[w:Daewoo Nubira|Daewoo Nubira]], [[w:Daewoo Tacuma|Daewoo Tacuma]], [[w:Chevrolet Optra|Chevrolet Optra]], [[w:Chevrolet Vivant|Chevrolet Vivant]], [[w:Holden Viva|Holden Viva (JF)]], [[w:Suzuki Forenza|Suzuki Forenza]], [[w:Suzuki Reno|Suzuki Reno]] 

This factory also produced Chevrolet vehicles for [[w:General Motors Europe|General Motors Europe]] and [[w:Chevrolet Europe|Chevrolet Europe]]. The factory permanently closed on May 31, 2018, due to low productivity caused by GM's withdrawal from Europe in 2017 and due to GM's restructuring of its GM Korea operations. Sold to Myoung Shin Co., Ltd. in 2018. Diesel engines were produced at an adjacent facility beginning in 2006.  

|- 

|A&lt;br /&gt;(1953-1964 [[w:Chevrolet|Chevrolet]] and 1965-1990)&lt;br /&gt;&lt;br /&gt;8 &lt;br /&gt;(1929-1952 [[w:Chevrolet|Chevrolet]])||[[w:Lakewood Assembly|Lakewood Assembly]]||[[w:Lakewood Heights, Atlanta|Lakewood Heights, Georgia]]||United States ||[[w:Chevrolet Caprice|Chevrolet Caprice]] (1966, 1987-1990)&lt;br /&gt;[[w:Pontiac Safari|Pontiac Safari wagon]] (1987-1989)&lt;br /&gt;[[w:Buick Estate#1977–1990|Buick LeSabre Estate wagon]] (1987-1989)&lt;br /&gt; [[w:Buick Estate#1977–1990|Buick Electra Estate wagon]] (1987-1989)&lt;br /&gt;[[w:Buick Estate#1977–1990|Buick Estate wagon]] (1990)||1928||1990||Located at McDonough Boulevard and Sawtell Avenue. Was part of the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were gradually transferred to the GM Assembly Division which replaced the BOP Assembly Division in 1965. Lakewood Assembly joined the GM Assembly Division in 1968. Idled from September 1982 to early 1984. Production ended with Chevrolet Caprice Classic &amp; Buick Estate Wagon. Last vehicle produced was a gray Chevy Caprice on &lt;br&gt; August 6, 1990.&lt;br /&gt; Past models:&lt;br /&gt; [[w:Chevrolet Series AC International|Chevrolet Series AC International]]&lt;br /&gt;[[w:Chevrolet Series AD Universal|Chevrolet Series AD Universal]]&lt;br /&gt;[[w:Chevrolet Series AE Independence|Chevrolet Series AE Independence]]&lt;br /&gt;[[w:Chevrolet Series BA Confederate|Chevrolet Series BA Confederate]]&lt;br /&gt;[[w:Chevrolet Standard Six|Chevrolet Standard Six]]&lt;br /&gt;[[w:Chevrolet Series CA Eagle / Master|Chevrolet Series CA Eagle / Master]]&lt;br /&gt;[[w:Chevrolet Master|Chevrolet Master]]&lt;br /&gt;[[w:Chevrolet Deluxe|Chevrolet Deluxe]]&lt;br /&gt;[[w:Chevrolet Fleetmaster|Chevrolet Fleetmaster]]&lt;br /&gt; [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1950-1966), [[w:Chevrolet 150|Chevrolet 150]] (1953-1957), [[w:Chevrolet 210|Chevrolet 210]] (1953-1957), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1958-1966), [[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958), [[w:Chevrolet El Camino#First generation (1959–1960)|Chevrolet El Camino]] (1959-1960), [[w:Chevrolet Impala|Chevrolet Impala]] (1958-1966), [[w:Chevrolet Nomad|Chevrolet Nomad]] (1955-1957), [[w:Chevrolet Suburban|Chevrolet Suburban]] (1957, 1965-1966).  Also built the &lt;br&gt; [[w:Chevrolet Chevette|Chevrolet Chevette]] (1981-1982, 1984-1987) &amp; [[w:Pontiac 1000|Pontiac 1000]] (1981-1982, 1984-1987),&lt;br&gt; [[w:Pontiac Acadian|Pontiac Acadian]] (Canada only).&lt;br&gt;  GM G-body: [[w:Pontiac Grand Prix#Third generation (1969–1972)|Pontiac Grand Prix]] (1970-1972). GM A-body: [[w:Chevrolet Chevelle|Chevrolet Chevelle]] (1964-1970), [[w:Chevrolet El Camino#Second generation (1964–1967)|Chevrolet El Camino]] (1965), [[w:Pontiac Grand Prix|Pontiac Grand Prix]] (1973-1979), [[w:Pontiac GTO|Pontiac GTO]] (1969, 1971-1973), [[w:Pontiac LeMans|Pontiac LeMans]] (1971-1977).&lt;br&gt; [[w:Chevrolet AK Series|Chevrolet AK Series]], [[w:Chevrolet Advance Design|Chevrolet Advance Design]] (1948-1955), [[w:Chevrolet Task Force|Chevrolet Task Force]] (1955-1959), [[w:Chevrolet C/K|Chevrolet C/K]] (1960-80), [[w:Chevrolet C/K (second generation)|GMC C/K (Action Line)]] (1967-1972),&lt;br&gt; [[w:Chevrolet C/K (third generation)|GMC C/K (Rounded Line)]] (1973-1980).  

|- 

|&amp;nbsp;||[[w:Lansing Car Assembly|Lansing Car Assembly - Body]]||[[w:Lansing, Michigan|Lansing, Michigan]]||United States||Automotive bodies||1920||2005||Located at 401 N. Verlinden St. Opened as a [[w:Durant Motors|Durant Motors]] plant in 1920. Durant Motors went out of business in 1931 and the plant was vacant until GM bought it in 1935. Known as GM's Lansing Plant 6. The plant reopened as a Fisher Body plant replacing the Fisher Body operation within the main Oldsmobile plant (Lansing Plant 1) that operated out of space leased from Oldsmobile since 1923. It supplied bodies to the main Oldsmobile plant (Lansing Plant 1 or Lansing Car Assembly - Chassis). Together with the chassis plant, they made up Lansing Car Assembly. Demolished in 2008-2009.  

|- 

|M (1949-1984 [All], 1985-2005 [North Line])||[[w:Lansing Car Assembly|Lansing Car Assembly - Chassis (North)]]||[[w:Lansing, Michigan|Lansing, Michigan]]||United States||,&lt;br&gt; [[w:Chevrolet Cavalier#Third generation (1995)|Chevrolet Cavalier coupe]] (1995-1998),&lt;br&gt; [[w:Chevrolet Malibu#Fifth generation (1997)|Chevrolet Malibu]] (2001-2003),&lt;br&gt; [[w:Chevrolet Malibu#Fifth generation (1997)|Chevrolet Classic]] (2004-2005),&lt;br&gt; [[w:Pontiac Grand Am|Pontiac Grand Am]] (1992-2005),&lt;br&gt; [[w:Oldsmobile Calais|Oldsmobile Calais]] (1985-1987),&lt;br&gt; [[w:Oldsmobile Cutlass Calais|Oldsmobile Cutlass Calais]] (1988-1991),&lt;br&gt; [[w:Oldsmobile Achieva|Oldsmobile Achieva]] (1992-1998),&lt;br&gt; [[w:Buick Skylark#Sixth generation (1985–1991)|Buick Somerset Regal/Somerset/Skylark]] (1985-1991)||1902||2005|| &quot;M&quot; - North assembly line. Part of GM's Lansing Plant 1. Located around 1014 Townsend St., next to the former Oldsmobile headquarters at 920 Townsend St. This was Oldsmobile's home plant. It predated the founding of GM in 1908. Fisher Body leased space here to build bodies for Oldsmobile beginning in 1923, when Fisher started making bodies for 1924 Oldsmobiles. In 1935, Fisher Body moved to the ex-Durant Motors plant on Verlinden St. that GM bought earlier that year. Oldsmobile then took back the space that Fisher Body had been using (Bldg. 26). Lansing Car Assembly was converted to build unibody, fwd, compact cars for 1985 for multiple GM brands instead of the previous body-on-frame, rwd midsize &amp; full-size cars exclusively for Oldsmobile. Demolished in 2007.  

Past models: [[w:Oldsmobile F-Series|Oldsmobile F-Series]] (1928-1938), [[w:Oldsmobile L-Series|Oldsmobile L-Series]] (1932-1938), [[w:Oldsmobile Series 60|Oldsmobile Series 60]] (1939-1948), [[w:Oldsmobile Series 70|Oldsmobile Series 70]] (1939-1950), [[w:Oldsmobile 88|Oldsmobile 88]] (1949-1984), Oldsmobile 80 (1939), [[w:Oldsmobile 98#First generation (1941)|Oldsmobile 90]] (1940), [[w:Oldsmobile 98#First generation (1941)|Oldsmobile 96]] (1941), [[w:Oldsmobile 98|Oldsmobile 98]] (1941-1984), [[w:Oldsmobile 98#1953|Oldsmobile 98 Fiesta]] convertible (1953),&lt;br&gt; [[w:Oldsmobile Custom Cruiser#First generation (1971–1976)|Oldsmobile Custom Cruiser]] (1971-1976), [[w:Oldsmobile Cutlass|Oldsmobile Cutlass]] (1961-1984), [[w:Oldsmobile Cutlass Supreme|Oldsmobile Cutlass Supreme]] (1966-1984), [[w:Oldsmobile 442|Oldsmobile 442]] (1964-80), [[w:Oldsmobile Jetstar I|Oldsmobile Jetstar I]] (1964-1965), [[w:Oldsmobile Starfire#First generation (1961–1966)|Oldsmobile Starfire]] (1961-1966), [[w:Oldsmobile Toronado|Oldsmobile Toronado]] (1966-1978), [[w:Oldsmobile Vista Cruiser|Oldsmobile Vista Cruiser]] (1964-1977), [[w:Viking (automobile)|Viking]] (1929-1931)&lt;br /&gt;Oldsmobile engines:&lt;br /&gt;[[w:Oldsmobile straight-6 engine|Oldsmobile straight-6 engine]]&lt;br /&gt;[[w:Oldsmobile straight-8 engine|Oldsmobile straight-8 engine]]&lt;br /&gt;[[w:Oldsmobile V8 engine|Oldsmobile Rocket V8 engine]]&lt;br /&gt;[[w:Oldsmobile V8 engine#Aluminum 215|Oldsmobile Rockette V8 engine]]&lt;br /&gt;[[w:Oldsmobile Diesel engine|Oldsmobile Diesel V8]]

|- 

|C (1985-2004 [South Line])||[[w:Lansing Car Assembly|Lansing Car Assembly - Chassis (South)]]||[[w:Lansing, Michigan|Lansing, Michigan]]||United States||[[w:Pontiac Grand Am|Pontiac Grand Am]] (1985-2004),&lt;br&gt; [[w:Oldsmobile Calais|Oldsmobile Calais]] (1985-1986),&lt;br&gt; [[w:Oldsmobile Alero|Oldsmobile Alero]] (1999-2004),&lt;br&gt; [[w:Chevrolet Alero|Chevrolet Alero]] (Export only: 1999-2001),&lt;br&gt; [[w:Buick Skylark#Seventh generation (1992–1998)|Buick Skylark]] (1992-1998)||1902||2004||&quot;C&quot; - South assembly line. Only started using a separate plant code from the North plant beginning with the 1985 N-body cars. Part of GM's Lansing Plant 1. Located around 1014 Townsend St., next to the former Oldsmobile headquarters at 920 Townsend St. Demolished in 2007.  

|- 

|B&lt;br /&gt;(0 for EV1)||[[w:Lansing Craft Centre|Lansing Craft Centre]]||[[w:Lansing Township, Michigan|Lansing Township, Michigan]]||United States||[[w:Chevrolet SSR|Chevrolet SSR]] (2003–2006)||1987||2006||Located at 2801 West Saginaw Street, across the street from the Lansing Metal Center. Originally built by Ryan-Bohn Foundry and opened in 1920. Owned by Driggs Aircraft Company from 1927-1930. Owned by R.E. Olds from 1930-1940 but not used. Bought by GM's Oldsmobile Division in 1940. Became GM's Lansing Plant 2. Also known as Olds Forge. Built artillery shells during WWII. Oldsmobile used this plant as a forge (through 1983) and for making axles and differentials (through 1984). Became known as the Oldsmobile Differential Plant and Foundry. Converted into a full vehicle assembly plant including stamping, body shop and general assembly areas. First opened as a vehicle assembly plant known as the Reatta Craft Centre in 1988 though pilot production began in December 1986. After Buick Reatta production ended in 1991, plant was renamed Lansing Craft Centre. Used by the Genasys joint venture with [[w:American Specialty Cars|ASC]] to complete production of the Chevy Cavalier and Pontiac Sunfire convertibles. Cavalier and Sunfire convertible production ends during 1999. Cadillac Eldorado production moved here from Detroit-Hamtramck Assembly during 2000. Eldorado production ended April 22, 2002. Plant was then converted to truck production for the Chevy SSR. First saleable production SSR completed on July 29, 2003. Final SSR built March 17, 2006. Closed in 2006. Demolished in 2008-2009. 

Past models: [[w:Buick Reatta|Buick Reatta]] (1988–1991), [[w:Chevrolet Cavalier#Third generation (1995)|Chevrolet Cavalier convertible]] (1995–2000), [[w:Pontiac Sunfire|Pontiac Sunfire]] convertible (1995–2000), [[w:General Motors EV1|General Motors EV1]] (1997, 1999), [[w:Cadillac Eldorado#Twelfth generation (1992–2002)|Cadillac Eldorado]] (2000-2002)

|- 

|||[[w:Lansing Engine Plant|Lansing Engine]]||[[w:Delta Township, Michigan|Delta Township, Michigan]]||United States||[[w:Oldsmobile Diesel engine|Oldsmobile Diesel V6]]&lt;br /&gt;[[w:Quad 4 engine|Quad 4 engine]]&lt;br /&gt;[[w:GM Ecotec engine|GM Ecotec engine]] (2002 only)||1981||2002||Located at 2901 S. Canal Road. Known as GM's Lansing Plant 5. Also known as Delta Engine. Built to produce experimental diesel engine; part of Ryder Logistics since 2005.  

|- 

|&amp;nbsp;||[[w:Lansing Metal Center|Lansing Metal Center]]||[[w:Lansing Township, Michigan|Lansing Township, Michigan]]||United States|| Stamping and electroplating bumpers; general machining of crankshafts and connecting rods; and machining, welding, and stamping of other automobile parts||1952||2006|| Located at 2800 W. Saginaw Street, across the street from the Lansing Craft Centre. Known as GM's Lansing Plant 3. Also known as the Olds Jet plant. Originally built to manufacture turbine blades for Buick-built J65 axial flow jet engines. Metal fabricating plant. Electroplating operation ended in May 1987. Closed in March 2006. Demolished in 2008-2010.  

|- 

|K &lt;br /&gt;(1953-1964 [[w:Chevrolet|Chevrolet]] and 1965-1988)&lt;br /&gt;&lt;br /&gt;5 (1929-1952 [[w:Chevrolet|Chevrolet]])&lt;br /&gt;&lt;br /&gt;M (1964 [[w:Pontiac (automobile)|Pontiac]])&lt;br /&gt;&lt;br /&gt;8 (1964 [[w:Buick|Buick]]) ||[[w:Leeds Assembly|Leeds Assembly]]||[[w:Kansas City, Missouri|Kansas City, Missouri]]||United States||[[w:Chevrolet Cavalier|Chevrolet Cavalier]] (1984-1987),&lt;br&gt; [[w:Oldsmobile Firenza|Oldsmobile Firenza]] (1982-1988),&lt;br&gt; [[w:Buick Skyhawk#Second generation (1982–1989)|Buick Skyhawk]] (1982-1988)&lt;br&gt;[[w:Pontiac Sunbird#Second generation (1982–1994)|Pontiac J2000]] (1982)||1929||1988||Located at 6817 Stadium Drive. Was part of the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Leeds Assembly began making Pontiac and Buick passenger cars for 1964. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were gradually transferred to the GM Assembly Division which replaced the BOP Assembly Division in 1965. Leeds Assembly joined the GM Assembly Division in 1968. Retooled to build fwd J-cars for 1982. Closed April 15, 1988. &lt;br /&gt;[[w:Chevrolet Series AD Universal|Chevrolet Series AD Universal]]&lt;br /&gt;[[w:Chevrolet Series AE Independence|Chevrolet Series AE Independence]]&lt;br /&gt;[[w:Chevrolet Series BA Confederate|Chevrolet Series BA Confederate]]&lt;br /&gt;[[w:Chevrolet Standard Six|Chevrolet Standard Six]]&lt;br /&gt;[[w:Chevrolet Series CA Eagle / Master|Chevrolet Series CA Eagle / Master]]&lt;br /&gt;[[w:Chevrolet Master|Chevrolet Master]]&lt;br /&gt;[[w:Chevrolet Deluxe|Chevrolet Deluxe]]&lt;br /&gt;[[w:Chevrolet Fleetmaster|Chevrolet Fleetmaster]]&lt;br /&gt;[[w:Buick Apollo|Buick Apollo]] (1974), [[w:Buick GS|Buick GS]] (1965-1968, 1970), [[w:Buick Regal|Buick Regal]] (1980-1981), [[w:Buick Skylark|Buick Skylark]] (1964-1970, 1975-76), [[w:Buick Special#1964–1967|Buick Special]] (1964-1967), [[w:Chevrolet 150|Chevrolet 150]] (1953-1957), [[w:Chevrolet 210|Chevrolet 210]] (1953-1957), [[w:Chevrolet AK Series|Chevrolet AK Series]], [[w:Chevrolet Advance Design|Chevrolet Advance Design]] (1947-1955), [[w:Chevrolet Task Force|Chevrolet Task Force]] (1955-1959), [[w:Chevrolet C/K (first generation)|Chevrolet C/K]] (1960-1966), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1950-1963), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1958-1963), [[w:Chevrolet Corvair|Chevrolet Corvair]] (1960-1961), [[w:Chevrolet Chevelle|Chevrolet Chevelle]] (1964-1974, 1977), [[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958), [[w:Chevrolet El Camino|Chevrolet El Camino]] (1964-1974, 1978-80), [[w:Chevrolet Impala|Chevrolet Impala]] (1958-1963), [[w:Chevrolet Malibu|Chevrolet Malibu]] (1978-1981), [[w:Chevrolet Monte Carlo|Chevrolet Monte Carlo]] (1971-1981), [[w:Chevrolet Nomad|Chevrolet Nomad]] (1955-1957), [[w:Chevrolet Nova|Chevrolet Chevy II/Nova]] (1962-63, 1974-1977),[[w:Chevrolet Suburban|Chevrolet Suburban]] (1952, 1956, 1959, 1961-1962), [[w:GMC Sprint|GMC Sprint]] (1971-1974), [[w:GMC Caballero|GMC Caballero]] (1978-1980), [[w:Pontiac GTO|Pontiac GTO]] (1964-1968), [[w:Pontiac LeMans|Pontiac LeMans]] (1964-1968), [[w:Pontiac Tempest|Pontiac Tempest]] (1964-1965)

|- 

|K ('94-'05)&lt;br /&gt;&lt;br /&gt;E ('65-'91)&lt;br /&gt;&lt;br /&gt;L (Pre-1965 [[w:Oldsmobile|Oldsmobile]] &amp; [[w:Pontiac (automobile)|Pontiac]]) &lt;br /&gt;&lt;br /&gt; 3 (Pre-1964 [[w:Buick|Buick]]) ||[[w:Linden Assembly|Linden Assembly]]||[[w:Linden, New Jersey|Linden, New Jersey]]||United States||[[w:Chevrolet S-10 Blazer#Second generation (1995)|Chevrolet Blazer]] (1995-2005)&lt;br /&gt;[[w:Chevrolet S-10 Blazer#Second generation (1995)|GMC Jimmy]] (1995-2005)&lt;br /&gt;[[w:Chevrolet S-10#Second generation (1994)|Chevrolet S-10]] (1994-2004)&lt;br /&gt; [[w:Chevrolet S-10#Second generation (1994)|GMC Sonoma]] (1994-2004)||1937||2005||Located at 1016 W. Edgar Road. Linden Assembly was the 2nd GM multi-brand assembly plant (the 1st was Southgate, CA), assembling Buick, Oldsmobile, and Pontiac models. It was operated by GM's Linden Division through January 1942. During WWII, GM built 5,837 [[w:FM-1 Wildcat|FM-1 Wildcat]] and [[w:FM-2 Wildcat|FM-2 Wildcat]] fighter planes at Linden under license from Grumman as part of GM's Eastern Aircraft Division. After the war ended, in 1945, Linden &amp; Southgate were both placed in a new division called the [[w:Buick-Oldsmobile-Pontiac Assembly Division|Buick-Oldsmobile-Pontiac Assembly Division]]. BOP Assembly Division became GM Assembly Division in 1965. In 1971, Linden Assembly became the first plant outside Cadillac's home plant in Detroit to assemble Cadillacs when it began to assemble C-body Cadillacs like the DeVille &amp; Calais. In 1979, Linden became the sole source for all three of GM's E-body personal luxury coupes, the Oldsmobile Toronado, Buick Riviera, and Cadillac Eldorado. The closely related K-body Cadillac Seville was added in 1980. In the mid-1980s, the factory was retooled to produce the new L-body Chevy Beretta &amp; Corsica, which began production in 1987. This was the first time Linden built a Chevrolet model. Linden was idled in September 1991 for conversion to truck and SUV production. It reopened in 1993 to produce the 1994 S-10 and Sonoma pickups, adding the Blazer and Jimmy SUVs for 1995. Closed April 2005. Last vehicle built was a white 2005 four-door Chevy Blazer on April 20, 2005. Demolished in 2008. Now Legacy Square, a complex of retail stores, and Legacy Commerce Center, an industrial space at the back of the property along Linden Ave.&lt;br /&gt; [[w:Chevrolet Corsica|Chevrolet Corsica]] (1987-1991), [[w:Chevrolet Beretta|Chevrolet Beretta]] (1987-1991), [[w:Buick Riviera#Sixth generation (1979–1985)|Buick Riviera]] (1979-1985), [[w:Oldsmobile Toronado#Third generation (1979–1985)|Oldsmobile Toronado]] (1979-1985), [[w:Cadillac Eldorado#Tenth generation (1979–1985)|Cadillac Eldorado]] (1979-1985), [[w:Cadillac Seville#Second generation (1980–1985)|Cadillac Seville]] (1980-85), [[w:Buick Century|Buick Century]] (1939, 1955-1957), [[w:Buick Electra|Buick Electra]] (1959-1963, 1971-1978), [[w:Buick Invicta|Buick Invicta]] (1959-1962), [[w:Buick LeSabre|Buick LeSabre]] (1959-1963), [[w:Buick Roadmaster|Buick Roadmaster]] (1948-1949, 1953-1957), [[w:Buick Special|Buick Special]] (1952-1957), [[w:Buick Super|Buick Super]] (1955-1957), [[w:Buick Wildcat|Buick Wildcat]] (1963), [[w:Cadillac Calais|Cadillac Calais]] (1971-1976), [[w:Cadillac DeVille|Cadillac DeVille]] (1971-1978), [[w:Oldsmobile 88|Oldsmobile 88]] (1949-1976), [[w:Oldsmobile 98|Oldsmobile 98]] (1941-1963, 1971-1978), [[w:Oldsmobile Cutlass|Oldsmobile Cutlass]] (1968-1970), [[w:Oldsmobile 442|Oldsmobile 442]] (1968-1970), [[w:Oldsmobile Jetstar I|Oldsmobile Jetstar I]] (1964-1965), [[w:Oldsmobile Starfire#First generation (1961–1966)|Oldsmobile Starfire]] (1961-1966), [[w:Pontiac Bonneville|Pontiac Bonneville]] (1958-1970, 1972-1973), [[w:Pontiac Catalina|Pontiac Catalina]] (1959-1970), [[w:Pontiac Chieftain|Pontiac Chieftain]] (1949, 1953, 1955, 1958), [[w:Pontiac Executive|Pontiac Executive]] (1967-1970), [[w:Pontiac Grand Prix|Pontiac Grand Prix]] (1962-1968), [[w:Pontiac Star Chief|Pontiac Star Chief]] (1955-1958, 1962, 1965-1966), [[w:Pontiac 2+2|Pontiac 2+2]] (1964-1967), [[w:Pontiac Ventura#1960–1970|Pontiac Ventura]] (1960-61) 

|-

|&amp;nbsp;||[[w:Livonia Engine|Livonia Engine]]||[[w:Livonia, Michigan|Livonia, Michigan]]||United States||[[w:Cadillac High Technology engine|Cadillac High Technology engine]] (4.1/4.5/4.9L OHV V8)&lt;br&gt;[[w:GM Premium V engine|Premium V engine]] (4.6L Northstar V8, 4.0L Aurora V8, 3.5L Shortstar V6)||1971||2010|| Located at 12200 Middlebelt Road. Originally built as a parts supplier to Cadillac. Converted into an engine plant for the HT-series V8 that debuted for 1982. Now a multi-tenant commercial space including [[w:Penske Corporation|Penske Logistics]] and [[w:KUKA|KUKA]]. The [[w:KUKA|KUKA]] facility appears to be the one building the initial batch of [[w:BrightDrop Zevo 600|BrightDrop Zevo 600]] electric vans for GM prior to production moving to GM's [[w:CAMI Automotive|CAMI Automotive]] plant.  

|- 

||7 (1979-2019)&lt;br /&gt;&lt;br /&gt; U&amp;nbsp;(1966-1978)||[[w:Lordstown Assembly|Lordstown Assembly]]||[[w:Warren, Ohio|Warren, Ohio]]||United States||[[w:Chevrolet Cruze#Second generation (J400)|Chevrolet Cruze (2016-2019)]]||1966||2019 

|GM bought the property in 1955 and announced plans for the new Chevrolet plant in 1956 but construction didn't begin until 1964. Production began on April 28, 1966. Was part of the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were gradually transferred to the GM Assembly Division which replaced the BOP Assembly Division in 1965. Lordstown Assembly joined the GM Assembly Division in 1971. &lt;br /&gt; Past models: [[w:Chevrolet Cruze#First generation (J300; 2008)|Chevrolet Cruze (2011-2015)/ Cruze Limited (2016)]], [[w:Chevrolet Cobalt|Chevrolet Cobalt]] (2005-2010)/[[w:Pontiac G5|Pontiac G5]] (2007-2009, Canada: 2007-2010), [[w:Chevrolet Cavalier|Chevrolet Cavalier]] (1982-2005)/[[w:Pontiac Sunbird#Second generation (1982–1994)|Pontiac J2000/2000/2000 Sunbird/Sunbird]] (1982-1994)/ [[w:Pontiac Sunfire|Pontiac Sunfire]] (1995-2004), [[w:Chevrolet Vega|Chevrolet Vega]] (1971–1977)/[[w:Pontiac Astre|Pontiac Astre]] (1975-1977), [[w:Chevrolet Monza|Chevrolet Monza]] (1978-1980)/[[w:Pontiac Sunbird#First generation (1976–1980)|Pontiac Sunbird]] (1978-1980)/[[w:Oldsmobile Starfire#Second generation (1975–1980)|Oldsmobile Starfire]] (1978-1980)/ [[w:Buick Skyhawk#First generation (1975–1980)|Buick Skyhawk]] (1978-1980), [[w:Chevrolet van#Third generation (1971-1996)|Chevrolet Van/Sportvan]] (1971-1992), [[w:Chevrolet van#Third generation (1971-1996)|GMC Vandura/ Rally Van]] (1971-1992), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1966-1970), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1966-1970), [[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-1970), [[w:Chevrolet Impala|Chevrolet Impala]] (1966-1970), [[w:Pontiac Firebird#First generation (1967–1969)|Pontiac Firebird]] (1967-1969), [[w:Pontiac Pursuit|Pontiac Pursuit/G5 Pursuit]] (Canada: 2005-2006), [[w:Toyota Cavalier|Toyota Cavalier]] (1996-2000).  

Located at 2300 Hallock-Young Road. Main assembly plant is the East part of the complex on Hallock-Young Road. Stamping plant added in 1970. Paint shop added in 2004. Stamping plant and paint shop are part of the West part of the complex on Ellsworth-Bailey Road. &lt;br /&gt; Closed on March 6, 2019. Sold to [[w:Lordstown Motors|Lordstown Motors]] in 2019. Lordstown Motors sold the plant to [[w:Foxconn|Foxconn]] in 2022 and Foxconn will do contract assembly for Lordstown Motors and others.  

|- 

|1 (Lotus Omega &amp;&lt;br /&gt;Lotus Carlton)&lt;br /&gt;&lt;br /&gt;H (Lotus models)||[[w:Lotus Cars|Lotus Cars]]||[[w:RAF Hethel|RAF Hethel]], [[w: Hethel|Hethel]], [[w:Norfolk|Norfolk]], [[w:England|England]]||[[w:United Kingdom|United Kingdom]]||

[[w:Opel Lotus Omega|Opel Lotus Omega]] A / [[w:Vauxhall Lotus Carlton|Vauxhall Lotus Carlton]]&lt;br /&gt; 1990-1992, 950 units 

 
[[w:Lotus Esprit|Lotus Esprit]], [[w:Lotus Excel|Lotus Excel]], [[w:Lotus Elan#Elan (M100)|Lotus Elan]]

||1986||1993||GM owned Lotus from 1986-1993. GM sold Lotus in 1993 to A.C.B.N. Holdings S.A. of Luxembourg, a company controlled by Italian businessman Romano Artioli, who also owned Bugatti Automobili SpA. Artioli sold Lotus to Malaysian automaker [[w:Proton Holdings|Proton]] in 1996. 

|- 

|&amp;nbsp;||Mansfield Metal Center||[[w:Ontario, Ohio|Ontario, Ohio]]||United States||Metal stamping||1955||2010||Located at 2525 W. 4th St. Mostly demolished. Redeveloped into Ontario Commerce Park.  

|- 

|&amp;nbsp;||[[w:Massena Castings Plant|Massena Castings Plant]]||[[w:Rooseveltown, New York|Rooseveltown, New York]]||United States|| Aluminum engine blocks &amp; cylinder heads for [[w:Chevrolet Turbo-Air 6 engine|Corvair engine]], Aluminum engine blocks for [[w:Chevrolet 2300 engine|Vega engine]], &amp; aluminum cylinder heads &amp; blocks for other engines.&lt;br /&gt; Also clutch housings, transmission cases, pistons, aluminum intake manifolds||1959||2009||Located at 56 Chevrolet Rd, Rooseveltown, NY 13662 &lt;br /&gt; Originally a Chevrolet facility. In 1978, became part of GM's Central Foundry Division. In 1991, Central Foundry became part of GM Powertrain. &lt;br /&gt;Production ended April 23, 2009. Demolished in 2011.

|- 

|M||Mexico City Assembly||[[w:Mexico City|Mexico City]]||[[w:Mexico|Mexico]]||[[w:Chevrolet|Chevrolet]] trucks &amp; vans||1937||1995&lt;ref&gt;{{cite news|author=Thomas H. Klier, James Rubenstein|title=Mexico’s Growing Role in the Auto Industry Under NAFTA: Who Makes What and What Goes Where|url=https://www.chicagofed.org/publications/economic-perspectives/2017/6.|publisher=Federal Reserve Bank of Chicago, Economic Perspectives, Vol. 41, No. 6|at=see table 11 and footnotes right under table 11|date=September 2017}}&lt;/ref&gt;||[[w:Chevrolet|Chevrolet]] including: Caprice, Chevelle, Corvair, Impala, Malibu, Nova, Malibu Rallye (Nova-based), trucks&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]], [[w:Oldsmobile|Oldsmobile]], [[w:Buick|Buick]], [[w:Cadillac|Cadillac]],&lt;br /&gt; [[w:Opel Olympia|Opel Olympia]],&lt;br&gt; [[w:Opel Rekord|Opel Rekord/MX-1/&lt;br&gt;Olimpico/Fiera]] &lt;br /&gt; Located at 843 Avenida Ejército Nacional (formerly Calzada de Los Morales) although the old headquarters building was demolished in 2018. The current headquarters is in the GM Tower at the other end of the property on Blvd. Miguel de Cervantes Saavedra. Started with trucks then added passenger cars in the early 1940s. Switched from assembly to manufacturing in 1965. Production ended in 1995 and most of the property was sold but GM de Mexico still has its corporate headquarters at this location. Most of the location is now Plaza Antara, an open-air shopping center. 

|- 

|2||[[w:Moraine Assembly|Moraine Assembly]]||[[w:Moraine, Ohio|Moraine, Ohio]]||United States||[[w:Chevrolet S-10#First generation (1982)|Chevrolet S-10]] (1982-1992)&lt;br /&gt; [[w:Chevrolet S-10 Blazer#First generation (1983–1994)|Chevrolet S-10 Blazer]] 4-door (1991-1994)&lt;br /&gt; [[w:Chevrolet S-10 Blazer#Second generation (1995–2005)|Chevrolet Blazer]] (1995-2001)&lt;br /&gt;[[w:GMC S-15#First generation (1982)|GMC S-15]] (1982-1990)&lt;br /&gt;[[w:GMC Sonoma#First generation (1982)|GMC Sonoma]] (1991-1992)&lt;br /&gt; [[w:GMC S-15 Jimmy#First generation (1983–1994)|GMC S-15 Jimmy/Jimmy]] 4-door (1991-1994)&lt;br /&gt; [[w:GMC S-15 Jimmy#Second generation (1995–2005)|GMC Jimmy]] (1995-2001)&lt;br /&gt;&lt;br /&gt; [[w:Chevrolet TrailBlazer#First generation (KC; 2001)|Chevrolet TrailBlazer]] (2002-2009)&lt;br /&gt; [[w:GMC Envoy#Second generation (2002–2009)|GMC Envoy]] (2002-2009)&lt;br /&gt; [[w:Isuzu Ascender|Isuzu Ascender]] (2003-2008)&lt;br /&gt;[[w:Oldsmobile Bravada|Oldsmobile Bravada]] (1991-1994, 1996-2004)&lt;br /&gt;[[w:Buick Rainier|Buick Rainier]] (2004-2007) &lt;br /&gt;[[w:Saab 9-7X|Saab 9-7X]] (2005-2009)&lt;br /&gt;&lt;br /&gt;[[w:Grumman LLV|Grumman LLV]] chassis (1987-1994)||1951&lt;br&gt;&lt;br&gt;1981 (Vehicle production)||2008|| Located at 2601 West Stroop Road. Began in 1951 as part of the [[w:Frigidaire|Frigidaire]] Division of General Motors Corporation producing household appliances. [[w:Frigidaire|Frigidaire]] production ended in 1979 when GM sold [[w:Frigidaire|Frigidaire]] to [[w:White Consolidated Industries|White Consolidated Industries]] but kept the Moraine plant and converted it to build vehicles. Vehicle production began in 1981. Was part of GM's Truck &amp; Bus Group. Closed on December 23, 2008. Sold to [[w:Fuyao Group#Fuyao Glass America Inc.|Fuyao Group]] in 2014; began production of automotive glass for GM and other automakers in 2016.  

|- 

|&amp;nbsp;||Moraine Engine||[[w:Moraine, Ohio|Moraine, Ohio]]||United States||[[w:Detroit Diesel V8 engine|Detroit Diesel V8 engine]] 6.2L/6.5L||1981||2000||Located at 4100 Springboro Pike. Also began as a [[w:Frigidaire|Frigidaire]] plant. Replaced by the nearby DMAX Ltd. engine plant (originally a joint venture with Isuzu) which builds the replacement engine ([[w:Duramax V8 engine|Duramax V8 engine]]). Demolished by 2003. Production of the 6.5-liter diesel V8 moved to a new AM General plant in Franklin, OH known as General Engine Products. AM General makes the engine for its own use and for GM service parts, &amp; 3rd party customers. 

|- 

|&amp;nbsp;||Muncie Transmission||[[w:Muncie, Indiana|Muncie, Indiana]]||United States||Transmissions including: [[w:Getrag 282 transmission|Getrag 282/NVG T550]], Getrag 284, Muncie M17, Muncie M20/M21/M22, Muncie M62/M64, [[w:Muncie SM420 transmission|Muncie SM420 transmission]], [[w:Muncie SM465 transmission|Muncie SM465 transmission]], [[w:New Venture Gear 3500 transmission|NV3500/NV3550]], [[w:New Venture Gear 4500 transmission|NV4500]]&lt;br /&gt;Valves, Steering gears&lt;br /&gt;Forge||1919||2006||Located at 1200 W. Eighth St. Originally founded as Warner Gear Company in 1902. Bought by GM in 1919. Became Muncie Products Division. Closed in 1932. Reopened by Chevrolet in 1935 (Chevrolet Muncie). Moved to Detroit Diesel Allison Division in 1984 &amp; then to Hydramatic Division in 1986. Became part of [[w:New Venture Gear|New Venture Gear]] joint venture with Chrysler in 1990. GM owned 36% while [[w:Chrysler|Chrysler]] owned 64%. GM sold its stake to [[w:DaimlerChrysler|DaimlerChrysler]] in 2002 but took back the Muncie plant. Became Manual Transmissions of Muncie. The plant closed in 2006. Demolished in 2008-09.  

|- 

|&amp;nbsp;||GM Near East||[[w:Alexandria|Alexandria]]|| [[w:Egypt|Egypt]]||[[w:Chevrolet|Chevrolet]] cars and trucks &lt;br /&gt;[[w:Buick|Buick]]||1936||1958||Began CKD assembly of trucks in 1936 followed by cars in 1938. In 1951, GM Near East became the Alexandria Branch of GM Middle East. Plant was liquidated in 1958.

|-

|&amp;nbsp;||[[w:General Motors New Zealand|General Motors New Zealand]]||[[w:Petone|Petone]]||[[w:New Zealand|New Zealand]]||[[w:Chevrolet|Chevrolet]] including [[w:Chevrolet Deluxe|Chevrolet Deluxe]], [[w:Chevrolet 210|Chevrolet 210]], [[w:Chevrolet Bel Air|Chevrolet Bel Air]], [[w:Chevrolet Impala|Chevrolet Impala]], [[w:Chevrolet Thriftmaster|Chevrolet Thriftmaster]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]] including [[w:Pontiac Laurentian|Pontiac Laurentian]], [[w:Pontiac Parisienne#New Zealand|Pontiac Parisienne]]&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]]&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:Opel Kadett#Kadett I (1936–1940)|Opel Kadett]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]] including [[w:Vauxhall Cresta|Vauxhall Cresta]] (E, PA, PC), [[w:Vauxhall Wyvern|Vauxhall Wyvern]], [[w:Vauxhall Velox|Vauxhall Velox]], [[w:Vauxhall Viva|Vauxhall Viva]], [[w:Vauxhall Victor|Vauxhall Victor]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford]] including [[w:Bedford CF|Bedford CF]], [[w:Bedford TK|Bedford TK]]&lt;br /&gt;[[w:Holden|Holden]] including [[w:Holden FE|Holden FE]], [[w:Holden FB|Holden FB]], [[w:Holden EJ|Holden EJ]], [[w:Holden EH|Holden EH]], [[w:Holden HD|Holden HD]]||1926||1984||Also made [[w:Frigidaire|Frigidaire]] refrigerators, freezers, washers, and dryers (Frigidaire was owned by GM from 1919 to 1979). &lt;br /&gt;  

Axle tube assemblies, oil filters, and spark plugs.  

|- 

|Z1-Z9 [https://forums.justcommodores.com.au/threads/commodore-vin-decoder-vb-to-zb.279978/]||[[w:General Motors New Zealand|General Motors New Zealand]]||[[w:Trentham, New Zealand|Trentham]]||[[w:New Zealand|New Zealand]]||[[w:Vauxhall Motors|Vauxhall]] including [[w:Vauxhall Chevette|Vauxhall Chevette]], [[w:Vauxhall Cresta#Cresta PC|Vauxhall Cresta]], [[w:Vauxhall Viva|Vauxhall Viva]]&lt;br /&gt;[[w:Holden|Holden]] including [[w:Holden HQ|Holden HQ]], [[w:Statesman (automobile)#HQ|Holden Statesman HQ]], [[w:Holden HJ|Holden HJ]], [[w:Statesman (automobile)#HJ|Holden Statesman HJ]], [[w:Holden HX|Holden HX]], [[w:Statesman (automobile)#HX|Holden Statesman HX]], [[w:Holden HZ|Holden HZ]], [[w:Statesman (automobile)#HZ|Holden Statesman HZ]], [[w:Statesman (automobile)#WB|Holden Statesman WB]],&lt;br /&gt; [[w:Holden Commodore (VB)|Holden Commodore (VB)]],&lt;br /&gt; [[w:Holden Commodore (VC)|Holden Commodore (VC)]],&lt;br /&gt; [[w:Holden Commodore (VH)|Holden Commodore (VH)]],&lt;br /&gt; [[w:Holden Commodore (VK)|Holden Commodore (VK)]],&lt;br /&gt; [[w:Holden Commodore (VL)|Holden Commodore (VL)]],&lt;br /&gt; [[w:Holden Commodore (VN)|Holden Commodore (VN)]], [[w:Holden Royale|Holden Commodore Royale (VH/VK/VL)]] &lt;br /&gt;[[w:Holden Torana|Holden Torana]]&lt;br /&gt; [[w:Isuzu Faster#Second generation (1980–1988)|Holden Rodeo]]&lt;br /&gt;[[w:Isuzu Gemini#In other markets|Isuzu Gemini/Holden Gemini]]&lt;br /&gt;[[w:Holden Camira|Holden Camira]]&lt;br /&gt;[[w:Holden Barina#First generation (MB, ML; 1985–1988)|Holden Barina]]&lt;br /&gt;[[w:Suzuki Cultus#First generation (1983)|Suzuki Swift]]&lt;br /&gt;[[w:Daihatsu Charade#First generation (G10, G20; 1977–1983)|Daihatsu Charade (under contract for Daihatsu)]]&lt;br /&gt;[[w:Datsun Truck#Nissan D21|Nissan Navara pickup (under contract for Nissan)]]||1967||1990|| 

|- 

|&amp;nbsp;||GM Nordiska AB||Södra Hammarbyhamnen, [[w:Stockholm|Stockholm]]||[[w:Sweden|Sweden]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Opel|Opel]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford]] trucks||1928||1957|| Converted into a warehouse in 1957. 

|- 

|&amp;nbsp;||Northway Motor Plant||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||Northway engines||1905||Burned down 1987||Located at 4584 Maybury Grand Ave. (Jeffries Expressway Service Drive) and W. Hancock St. Around 4646 Lawton St. (rear side) is the remnants of a water tower and railroad spur. Northway Motor and Manufacturing Company was acquired by GM in 1909, becoming Northway Motor and Manufacturing Division. Northway had made engines for both GM brands (in particular [[w:Oakland Motor Car Company|Oakland]], [[w:Oldsmobile|Oldsmobile]], [[w:Sheridan (automobile)|Sheridan]], [[w:Scripps-Booth|Scripps-Booth]], [[w:Samson Tractor|Samson Tractor]], and [[w:GMC (automobile)|GMC]]) and other automakers. Became part of GM Intercompany Parts Group. In 1920, Northway moved to a new plant on Holbrook Ave. in Detroit. This address was subsequently been used by [[w:Frigidaire|Frigidaire]] in the 1920's and 1930's and then by Refrigeration Service Inc. in the 1950's. At some point, the building was sold to Motor City Wiping Cloth Co. but they abandoned the property in 1983, leaving behind massive bales of rags and cloths. The building burned down in a horrific fire in 1987 after homeless people in the building were burning fires there to keep warm. The fire killed three firefighters and injured ten others. The fire even spread to the nearby Continental Paper warehouse. 

|- 

|&amp;nbsp;||Northway Motor Plant/General Motors Truck Co. Plant No. 7/ &lt;br&gt;Chevrolet Gear and Axle Div.||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||Northway engines, Axles, parts for past model Chevrolets||1920||1994||Located at 1806 Holbrook Ave. Northway Motor and Manufacturing Company was acquired by GM in 1909, becoming Northway Motor and Manufacturing Division. Northway had made engines for both GM brands (in particular [[w:Oakland Motor Car Company|Oakland]], [[w:Oldsmobile|Oldsmobile]], [[w:Sheridan (automobile)|Sheridan]], [[w:Scripps-Booth|Scripps-Booth]], [[w:Samson Tractor|Samson Tractor]], and [[w:GMC (automobile)|GMC]]) and other automakers. Became part of GM Central Products Division. In 1920, Northway moved here from their original plant on Maybury Grand Ave. and primarily supplied engines to GMC. In 1925, became part of Yellow Truck &amp; Coach Manufacturing Company as part of the merger of Yellow Cab Manufacturing Company and General Motors Truck Corp., the manufacturer of GMC trucks. In 1926, Northway Motor Division was liquidated and its Detroit plant was sold to Chevrolet on March 31 to become the Chevrolet Gear and Axle Div.  Part of the engine tooling machinery was transferred to the Yellow Sleeve-Valve Engine Works at East Moline, IL. Some Northway engines were still used by some GMC trucks (K-series) through 1930. Was part of the Detroit complex sold to [[w:American Axle|American Axle]] in 1994. Now part of American Axle's Advanced Technology Development Center.  

|- 

|N&lt;br /&gt;(1953-1964 [[w:Chevrolet|Chevrolet]]) and 1965-1987&lt;br /&gt;&lt;br /&gt;9 &lt;br /&gt;(1928-1952 [[w:Chevrolet|Chevrolet]])||[[w:Norwood Assembly|Norwood Assembly]]||[[w:Norwood, Ohio|Norwood, Ohio]]||United States||[[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1950-1961)&lt;br /&gt;[[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1958-1961)&lt;br /&gt;[[w:Chevrolet Camaro|Chevrolet Camaro]] (1967-1987)&lt;br /&gt;[[w:Chevrolet Caprice|Chevrolet Caprice]] (1966)&lt;br /&gt;[[w:Chevrolet El Camino#First generation (1959–1960)|Chevrolet El Camino]] (1959-1960)&lt;br /&gt;[[w:Chevrolet Impala|Chevrolet Impala]]&lt;br /&gt; (1958-1961, 1965-1966)&lt;br /&gt;[[w:Chevrolet Nomad|Chevrolet Nomad]] (1955-1957)&lt;br /&gt;[[w:Chevrolet Nova|Chevrolet Chevy II/Nova]]&lt;br&gt; (1962-1966, 1972)&lt;br /&gt;[[w:Pontiac Firebird|Pontiac Firebird]] (1969-1987)&lt;br /&gt;[[w:Buick Apollo|Buick Apollo]] (1973)||1923||1987||Located at 5025 Carthage Ave. First vehicle produced was a Chevrolet Superior on August 13, 1923. Was part of the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were gradually transferred to the GM Assembly Division which replaced the BOP Assembly Division in 1965. Norwood Assembly joined the GM Assembly Division in 1971.  Closed August 26, 1987. Last vehicle produced was a Chevy Camaro IROC-Z. Demolished. Now Linden Pointe on the Lateral, a mixed use retail and office space. &lt;br /&gt;[[w:Chevrolet Superior|Chevrolet Superior]]&lt;br /&gt;[[w:Chevrolet Series AA Capitol|Chevrolet Series AA Capitol]]&lt;br /&gt;[[w:Chevrolet Series AB National|Chevrolet Series AB National]]&lt;br /&gt;[[w:Chevrolet Series AC International|Chevrolet Series AC International]]&lt;br /&gt;[[w:Chevrolet Series AD Universal|Chevrolet Series AD Universal]]&lt;br /&gt;[[w:Chevrolet Series AE Independence|Chevrolet Series AE Independence]]&lt;br /&gt;[[w:Chevrolet Series BA Confederate|Chevrolet Series BA Confederate]]&lt;br /&gt;[[w:Chevrolet Standard Six|Chevrolet Standard Six]]&lt;br /&gt;[[w:Chevrolet Series CA Eagle / Master|Chevrolet Series CA Eagle / Master]]&lt;br /&gt;[[w:Chevrolet Master|Chevrolet Master]]&lt;br /&gt;[[w:Chevrolet Deluxe|Chevrolet Deluxe]]&lt;br /&gt;[[w:Chevrolet Stylemaster|Chevrolet Stylemaster]]&lt;br /&gt;[[w:Chevrolet Fleetmaster|Chevrolet Fleetmaster]]&lt;br /&gt;[[w:Chevrolet 150|Chevrolet 150]] (1953-1957)&lt;br /&gt;[[w:Chevrolet 210|Chevrolet 210]] (1953-1957)&lt;br /&gt;[[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958)&lt;br /&gt;[[w:Chevrolet AK Series|Chevrolet AK Series]]&lt;br /&gt;[[w:Chevrolet Advance Design|Chevrolet Advance Design]] (1947-1955)&lt;br /&gt;[[w:Chevrolet Task Force|Chevrolet Task Force]] (1955-1959)&lt;br /&gt;[[w:Chevrolet C/K (first generation)|Chevrolet C/K]] (1960-1966)&lt;br /&gt;[[w:Chevrolet Suburban|Chevrolet Suburban]] (1952)

|- 

|Z||[[w:NUMMI|NUMMI]]||[[w:Fremont, California|Fremont, California]]||United States||[[w:Chevrolet Chevy II / Nova#Fifth generation (1985–1988)|Chevrolet Nova]] (1985-1988)&lt;br /&gt;[[w:Geo Prizm|Geo Prizm]] (1989-1997)&lt;br /&gt;[[w:Chevrolet Prizm|Chevrolet Prizm]] (1998-2002)&lt;br /&gt;[[w:Pontiac Vibe|Pontiac Vibe]] (2003-2010)&lt;br /&gt;[[w:Toyota Corolla (E80)|Toyota Corolla FX]] (1987-1988)&lt;br /&gt;[[w:Toyota Corolla|Toyota Corolla]] (1989-2010) (E90/E100/E110/E130/E140)&lt;br /&gt;[[w:Toyota Hilux#Fifth generation (N80, N90, N100, N110; 1988)|Toyota Pickup]] (1992-1995)&lt;br /&gt;[[w:Toyota Tacoma|Toyota Tacoma]] (1995-2010)&lt;br /&gt;[[w:Toyota Voltz|Toyota Voltz]] (Japan: '02-'04)||1984||2009||Located at 45500 Fremont Blvd.&lt;br /&gt; Operated from 1963-1982 as a GM factory.&lt;br /&gt;From 1984-2010, operated as [[w:NUMMI|New United Motor Manufacturing Inc. (NUMMI)]], which was a 50/50 joint venture between GM and [[w:Toyota|Toyota]] and assembled both GM and Toyota vehicles. First vehicle produced was a yellow Chevrolet Nova in December 1984. First Toyota produced was a Corolla FX16 3-d hatchback in September 1986. This was followed by the Corolla FX 3-d hatchback in February 1987. Nova and Corolla FX production ended in September 1988. That same month, NUMMI began producing the Toyota Corolla 4-door sedan. Geo Prizm production began in November 1988. In August 1991, Toyota pickup production began with the Regular Cab 4x2. The 4x4 followed in February 1992 ant the Xtracab followed in March 1993. Tacoma pickup production began in January 1995, replacing the previous unnamed Toyota pickup model. Prizm production ended in December 2001. In January 2002, Pontiac Vibe production began. In June 2002, production began of the Toyota Voltz, a rhd version of the Pontiac Vibe built for export to Japan. In September 2004, the 2nd generation Tacoma pickup began production. Pontiac Vibe production ended on August 17, 2009, ending GM production at Fremont. Tacoma pickup production ended March 26, 2010. The last vehicle built at NUMMI, a red Corolla sedan, was built April 1, 2010. NUMMI produced 7.7 million vehicles. &lt;br /&gt;Sold to [[w:Tesla Motors|Tesla, Inc.]] in May 2010.&lt;ref&gt;{{cite news|author=Sam Abuelsamid|title=Tesla to buy old resources from GM, Toyota for NUMMI plant|url=http://www.autoblog.com/2010/08/22/tesla-to-buy-old-resources-from-gm-toyota/|access-date=20 August 2015|publisher=Autoblog.com|date=August 22, 2010}}&lt;/ref&gt; Tesla only bought 210 of the total 370 acres owned by NUMMI. Tesla also bought $15 million worth of equipment and parts from the former NUMMI plant. Tesla took possession of the plant in October 2010. Tesla began production at Fremont in June 2012 with the Model S.

|- 

|O &lt;br /&gt;(1953-1963 [[w:Chevrolet|Chevrolet]])&lt;br /&gt;&lt;br /&gt;6 &lt;br /&gt;(1928-1952 [[w:Chevrolet|Chevrolet]])&lt;br /&gt;&lt;br /&gt;C ([[w:GMC (automobile)|GMC]])||[[w:Oakland Assembly|Oakland Assembly]] (Chevrolet)||[[w:Oakland, California|Oakland, California]]||United States||[[w:Chevrolet Series 490|Chevrolet Series 490]]&lt;br /&gt;[[w:Chevrolet Superior|Chevrolet Superior]]&lt;br /&gt;[[w:Chevrolet Series AA Capitol|Chevrolet Series AA Capitol]]&lt;br /&gt;[[w:Chevrolet Series AB National|Chevrolet Series AB National]]&lt;br /&gt;[[w:Chevrolet Series AC International|Chevrolet Series AC International]]&lt;br /&gt;[[w:Chevrolet Series AD Universal|Chevrolet Series AD Universal]]&lt;br /&gt;[[w:Chevrolet Series AE Independence|Chevrolet Series AE Independence]]&lt;br /&gt;[[w:Chevrolet Series BA Confederate|Chevrolet Series BA Confederate]]&lt;br /&gt;[[w:Chevrolet Standard Six|Chevrolet Standard Six]]&lt;br /&gt;[[w:Chevrolet Series CA Eagle / Master|Chevrolet Series CA Eagle / Master]]&lt;br /&gt;[[w:Chevrolet Master|Chevrolet Master]]&lt;br /&gt;[[w:Chevrolet Deluxe|Chevrolet Deluxe]]&lt;br /&gt;[[w:Chevrolet Stylemaster|Chevrolet Stylemaster]]&lt;br /&gt;[[w:Chevrolet Fleetmaster|Chevrolet Fleetmaster]]&lt;br /&gt;[[w:Chevrolet 150|Chevrolet 150]] (1953-1957)&lt;br /&gt;[[w:Chevrolet 210|Chevrolet 210]] (1953-1957)&lt;br /&gt;[[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1950-1963)&lt;br /&gt;[[w:Chevrolet Corvair|Chevrolet Corvair]] (1960-1963)&lt;br /&gt;[[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958)&lt;br /&gt;[[w:Chevrolet Impala|Chevrolet Impala]] (1958-1963)&lt;br /&gt;[[w:Chevrolet Nova|Chevrolet Chevy II/Nova]] (1962-1963)&lt;br /&gt;[[w:Chevrolet Advance Design|Chevrolet Advance Design]] (1947-1955)&lt;br /&gt;[[w:Chevrolet Task Force|Chevrolet Task Force]] (1955-1959)&lt;br /&gt;[[w:Chevrolet C/K (first generation)|Chevrolet C/K]] (1960-1963)&lt;br /&gt;[[w:GMC New Design|GMC New Design]] (1952-1954)&lt;br /&gt;[[w:GMC Blue Chip|GMC Blue Chip]] (1955-1959)&lt;br /&gt;[[w:Chevrolet C/K (first generation)|GMC C/K]] (1960-1963)&lt;br /&gt;[[w:Chevrolet Suburban|Chevrolet Suburban]] (1952-1953, 1955, 1957, 1959, 1963)&lt;br /&gt;[[w:GMC Suburban|GMC Suburban]]||1917||1963||Located at 73rd Ave. &amp; Foothill Blvd. Built by Chevrolet before it became part of GM. Began building GMC trucks in December 1937 for the 1938 model year. Replaced by Fremont Assembly plant. Demolished. Site became Eastmont Mall which is now [[w:Eastmont Town Center|Eastmont Town Center]].  

|- 

|&amp;nbsp;||[[w:Oakland Motor Car Company|Oakland Motor Car Co.]]||[[w:Pontiac, Michigan|Pontiac, Michigan]]||United States||Oakland automobiles &lt;br /&gt; Pontiac 1926-1927||1909||1931||Located at 196 Oakland Ave. (now Cesar E Chavez Ave.). Also bordered by Baldwin Ave. and W. Howard St. GM bought Oakland Motor Car Co. in 1909. Oakland introduced sister brand Pontiac in 1926. Pontiac replaced Oakland for 1932. Early Pontiacs were built here before production moved to the new factory stretching from Baldwin Ave. east to Joslyn Ave. a little farther north. This was Pontiac's first headquarters until 1970 when Pontiac headquarters moved north to the Pontiac Assembly complex on Joslyn Ave. and &lt;br&gt; E. Montcalm St. Some of the buildings are still standing.

|-

|&amp;nbsp;||[[w:es:General Motors OBB|GM-OBB]]||[[w:Quito, Ecuador|Quito]]||[[w:Ecuador|Ecuador]]||[[w:Isuzu D-Max#Second generation (RT; 2011)|Chevrolet D-Max 2011]]||1980 (1st GM product)||2024||OBB (Ómnibus BB Transportes) was founded in 1975. GM bought 22% of OBB in 1981 &amp; became majority shareholder in 1988. GM announced in April 2024 that GM-OBB will shut down at the end of August 2024.&lt;ref&gt;{{Cite web|url=https://gmauthority.com/blog/2024/04/gm-shutting-down-manufacturing-operations-in-colombia-and-ecuador/|title = GM Shutting Down Manufacturing Operations In Colombia And Ecuador|author=Deivis Centeno|publisher=GMAuthority.com|date = April 29, 2024}}&lt;/ref&gt;&lt;ref&gt;{{Cite web|url=https://www.americaeconomia.com/en/business-industries/general-motors-announces-end-car-manufacturing-operations-colombia-and-ecuador/|title = General Motors announces the end of car manufacturing operations in Colombia and Ecuador|publisher=AmericaEconomia.com|date = April 26, 2024}}&lt;/ref&gt;

Past models: [[w:Chevrolet Aveo (T200)|Chevrolet Aveo]]&lt;br /&gt;[[w:Chevrolet K5 Blazer|Chevrolet K5 Blazer]]&lt;br /&gt;[[w:Opel Corsa#Corsa B (S93; 1993)|Chevrolet Corsa]], [[w:Opel Corsa#Corsa C (X01; 2000)|Chevrolet Corsa Evolution]]&lt;br /&gt;[[w:Suzuki Cultus Crescent|Chevrolet Esteem]], [[w:Suzuki Cultus#Second generation (1988)|Chevrolet Forsa]]&lt;br /&gt;[[w:Isuzu Gemini#Second generation (1985)|Chevrolet Gemini]]&lt;br /&gt;[[w:Isuzu Faster#TF|Chevrolet LUV]], [[w:Isuzu D-Max#First generation (RA, RC; 2002)|Chevrolet LUV D-Max]]&lt;br /&gt;[[w:Isuzu MU#First generation (UCS55/UCS69GW; 1989–1998)|Chevrolet Rodeo]], [[w:Isuzu Trooper#First generation (1981–1991)|Chevrolet Trooper]]&lt;br /&gt;[[w:Chevrolet Sail#Second generation (2010)|Chevrolet Sail (Gen 2)]], [[w:Chevrolet Sail#Third generation (2014)|Chevrolet Sail (Gen 3)]]&lt;br /&gt;[[w:Chevrolet C/K (third generation)|Chevrolet Silverado]]&lt;br /&gt;[[w:Chevrolet Tracker (Americas)|Chevrolet Vitara]], [[w:Chevrolet Tracker (Americas)#Second generation|Chevrolet Grand Vitara]], [[w:Suzuki Vitara#Third generation (JT; 2005)|Chevrolet Grand Vitara SZ]] 

|- 

|6||[[w:Oklahoma City Assembly|Oklahoma City Assembly]]||[[w:Oklahoma City, Oklahoma|Oklahoma City, Oklahoma]]||United States||[[w:Chevrolet Trailblazer (SUV)#EXT|Chevrolet TrailBlazer EXT]] (2002-2006)&lt;br /&gt;[[w:GMC Envoy XL#Second generation (2002–2009)|GMC Envoy XL]] (2002-2006)&lt;br /&gt;[[w:GMC Envoy#Envoy XUV|GMC Envoy XUV]] (2004-2005)&lt;br /&gt;[[w:Isuzu Ascender|Isuzu Ascender extended length]] (2003-2006)||1979||2006||Located at 7447 SE 74th Street. &lt;br /&gt; Initially produced front wheel drive [[w:GM X platform (FWD)|X platform]] vehicles ([[w:Chevrolet Citation|Chevrolet Citation]] (1980-1983) &amp; [[w:Pontiac Phoenix#Second generation (1980–1984)|Pontiac Phoenix]] (1980-1982)) followed by front wheel drive [[w:General Motors A platform (FWD)|A platform]] vehicles ([[w:Chevrolet Celebrity|Chevrolet Celebrity]] (1982-1989), [[w:Pontiac 6000|Pontiac 6000]] (1988-1991), [[w:Oldsmobile Cutlass Ciera|Oldsmobile Cutlass Ciera]] (1989-1996), [[w:Buick Century#Fifth generation (1982–1996)|Buick Century]] (1982-1996)) as well as [[w:Chevrolet Malibu#Fifth generation (1997)|Chevrolet Malibu]] (1997-2001) &amp; [[w:Oldsmobile Cutlass#Sixth generation (midsize) 1997–1999|Oldsmobile Cutlass]] (1997-1999). Converted to build body-on-frame SUVs for 2002 model year. Damaged by a tornado on May 8, 2003, but the company repaired the damage and returned the plant to operation just 53 days later. Idled February 20, 2006. Last vehicle produced was a white 2006 Chevrolet TrailBlazer EXT. Plant was taken over by Oklahoma City in 2008 and leased to neighbor Tinker Air Force Base. Now known as Building 9001 Tinker Aerospace Complex. Used for maintaining jet engines and for software engineering.  

|- 

|2||[[w:Opel|Opel]] Werk Bochum||[[w:Bochum|Bochum]], [[w:North Rhine-Westphalia|North Rhine-Westphalia]]||[[w:Germany|Germany]]||[[w:Opel Olympia#Name revival: Opel Olympia (1967–1970)|Opel Olympia]] A&lt;br /&gt;[[w:Opel Ascona|Opel Ascona]] A, B&lt;br /&gt;[[w:Opel Kadett|Opel Kadett]] A, B, C, D, &amp; E&lt;br /&gt;[[w:Opel Astra|Opel Astra]] F, G, &amp; H&lt;br /&gt;[[w:Opel Astra#H|Opel Astra]] H Classic (5-door, Caravan)&lt;br /&gt;[[w:Opel GT#GT (1968–1973)|Opel GT]]&lt;br /&gt;[[w:Opel Manta|Opel Manta]] A, B&lt;br /&gt;[[w:Opel Zafira#Zafira Tourer C (2011–2019)|Opel/Vauxhall Zafira Tourer]] C&lt;br /&gt;[[w:Opel Zafira#Zafira B (2005–2014)|Opel/Vauxhall Zafira]] B/Zafira Family&lt;br /&gt;[[w:Opel Zafira#Zafira A (1999–2006)|Opel/Vauxhall Zafira]] A&lt;br /&gt;[[w:Vauxhall Astra|Vauxhall Astra]]&lt;br /&gt;Engines&lt;br /&gt;Transmissions&lt;br /&gt;Axles||1962||2014|| Plant I was the vehicle assembly plant. First car off the line was a Kadett A. Plant II was the engine, transmission, &amp; axle plant. Engine production ended in 2004. Axle production ended in 2011. Transmission production ended Oct. 7, 2013. Vehicle production ended December 5, 2014. 

|- 

|&amp;nbsp;||[[w:Opel|Opel]] [[w:Opelwerk Brandenburg|Werk Brandenburg]]||[[w:Brandenburg an der Havel|Brandenburg an der Havel]], [[w:Brandenburg|Brandenburg]]||[[w:Germany|Germany]]||[[w:Opel Blitz|Opel Blitz]]&lt;br /&gt;||1935||1944|| Bombed and heavily damaged by the Allies on Aug. 6, 1944. Factory was dismantled and shipped to the Soviet Union after the war ended as reparations. 

|- 

|6||[[w:Opel Eisenach|Opel Eisenach GmbH]]||[[w:Eisenach|Eisenach]], [[w:Thuringia|Thuringia]]||[[w:Germany|Germany]]||[[w:Opel Corsa#Corsa E (X15; 2014)|Opel/Vauxhall Corsa]] E (3-door)&lt;br /&gt;[[w:Opel Corsa#Corsa D (S07; 2006)|Opel/Vauxhall Corsa]] D (3-door)&lt;br /&gt;[[w:Opel Corsa#Corsa C (X01; 2000)|Opel/Vauxhall Corsa]] C (3-door)&lt;br /&gt;[[w:Opel Corsa#Corsa B (S93; 1993)|Opel/Vauxhall Corsa]] B &lt;br /&gt; [[w:Opel Adam|Opel/Vauxhall Adam]]&lt;br /&gt;[[w:Opel Astra#F|Opel Astra F]] (1992-1995)&lt;br /&gt;[[w:Opel Astra#G|Opel Astra G]] (1998-2003)||1992||2017|| [[w:Adam Opel AG|Opel plant]]. Began production with Astra F in 1992. Began Corsa production in 1993 with Corsa B. Added production of the Adam in 2013. Sold to [[w:PSA Group|PSA Group]] in 2017. Part of [[w:Stellantis|Stellantis]] since 2021. 

|- 

|&amp;nbsp;||[[w:Adam Opel AG|Opel]] Werk Kaiserslautern||[[w:Kaiserslautern|Kaiserslautern]], [[w:Rhineland-Palatinate|Rhineland-Palatinate]]||[[w:Germany|Germany]]||Components&lt;br /&gt;Engines:&lt;br /&gt; Four-cylinder turbo diesel engines:&lt;br /&gt; [[w:Fiat JTD engine#2.0 Multijet II|2.0 CDTI Family B turbodiesel 4-cyl.]]&lt;br /&gt;[[w:Fiat JTD engine#1.9|1.9 CDTI turbodiesel 4-cyl.]]&lt;br /&gt; [[w:GM Ecotec Diesel (1997)|2.0/2.2 Ecotec direct injection turbodiesel]]

Four-cylinder gasoline engines:&lt;br /&gt; [[w:GM Ecotec engine|GM Ecotec engine]] 2.2&lt;br /&gt;[[w:GM Ecotec engine#2.0|GM Ecotec engine]] 2.0 supercharged (LSJ) &lt;br /&gt;[[w:GM Family II engine|GM Family II engine]] 1.6, 1.8, 2.0 &lt;br /&gt; 


|1966||2017||[[w:Adam Opel AG|Opel plant]]. Sold to [[w:PSA Group|PSA Group]] in 2017. Part of [[w:Stellantis|Stellantis]] since 2021. 

|- 

|1&lt;br /&gt;&lt;br /&gt;R (Catera)&lt;br /&gt;&lt;br /&gt;5 (Pre-1976)||[[w:Adam Opel AG|Opel]] Werk Rüsselsheim||[[w:Rüsselsheim|Rüsselsheim]], [[w:Hesse|Hesse]]||[[w:Germany|Germany]]||[[w:Opel Insignia|Opel/Vauxhall Insignia]] (sedan, hatchback, Sports Tourer, Country Tourer)&lt;br /&gt;[[w:Buick Regal#Fifth generation (2008)|Buick Regal]] (2011MY from March 1, 2010-March 25, 2011)&lt;br /&gt;[[w:Buick Regal#Sixth generation (2018)|Buick Regal]] (2018-2020)&lt;br /&gt;[[w:Holden Insignia#First generation (G09; 2008)|Holden Insignia VXR (GA)]] (2015-2017)&lt;br /&gt;[[w:Holden Commodore ZB|Holden Commodore (ZB)]] (2018-2020)&lt;br /&gt;[[w:Opel Astra#J|Opel/Vauxhall Astra J]] (5-door)&lt;br /&gt;[[w:Opel Zafira|Opel/Vauxhall Zafira Tourer C]]&lt;br /&gt;[[w:Opel Vectra|Opel/Vauxhall Vectra]]&lt;br /&gt;[[w:Opel Vectra#Vectra B (1995–2002)|Holden Vectra (JR)]]&lt;br /&gt;[[w:Opel Vectra#Vectra C (2002–2010)|Holden Vectra (ZC)]]&lt;br /&gt;[[w:Opel Signum|Opel/Vauxhall Signum]]&lt;br /&gt;[[w:Opel Omega|Opel/Vauxhall Omega]]&lt;br /&gt;[[w:Cadillac Catera|Cadillac Catera]] (1997-2001)&lt;br /&gt;[[w:Opel Senator|Opel/Vauxhall Senator &amp; Vauxhall Royale]]&lt;br /&gt;[[w:Opel Calibra|Opel/Vauxhall/Holden Calibra (YE)]]&lt;br /&gt;[[w:Opel Monza|Opel Monza/Vauxhall Royale Coupe]]&lt;br /&gt;[[w:Opel Commodore|Opel Commodore/Vauxhall Viceroy]]&lt;br /&gt;[[w:Opel Kapitan|Opel Kapitan]]&lt;br /&gt;[[w:Opel Admiral|Opel Admiral]]&lt;br /&gt;[[w:Opel Diplomat|Opel Diplomat]]&lt;br /&gt;[[w:Opel Kadett#Kadett I (1936–1940)|Opel Kadett]]&lt;br /&gt;[[w:Opel Olympia|Opel Olympia]]&lt;br /&gt;[[w:Opel Blitz|Opel Blitz]]&lt;br /&gt;axles&lt;br /&gt;components&lt;br /&gt;[[w:GM F40 transmission|GM F40 transmission]]&lt;br /&gt;Frigidaire refrigerators (1937-c.1940 &amp; 1946-1959)||1899 (1st production car built)&lt;br&gt;&lt;br&gt; 1929 (part of GM)||2017 (left GM)&lt;br&gt;&lt;br&gt;2020 (production for GM ended)|| [[w:Adam Opel AG|Opel plant]]. GM bought 80% of Opel in March 1929 and bought the rest in 1931, making Opel a full GM subsidiary. Russelsheim previously make engines. Sold to [[w:PSA Group|PSA Group]] in 2017. Rüsselsheim continued to supply the Buick Regal &amp; the Holden Commodore ZB to GM through 2020. Part of [[w:Stellantis|Stellantis]] since 2021. 

|- 

|S||[[w:Opel Szentgotthárd|Opel Szentgotthárd]]||[[w:Szentgotthárd|Szentgotthárd]]||[[w:Hungary|Hungary]]||[[w:Opel Astra|Opel Astra]] F 1992-1997, 80,835 units&lt;br /&gt;[[w:Opel Vectra#Vectra B (1995–2002)|Opel Vectra]] B1 and B2 1998-1999, 4,404 units&lt;br /&gt;Opel Engines including:&lt;br /&gt; [[w:GM Family 1 engine| Family 1 engine]] DOHC versions 1.4, 1.6, 1.8&lt;br /&gt;[[w:GM small gasoline engine|GM Small Gasoline Engine]]&lt;br /&gt;[[w:GM Medium Gasoline Engine|GM Medium Gasoline Engine]]&lt;br /&gt;[[w:GM Medium Diesel engine|GM Medium Diesel engine]]&lt;br /&gt;[[w:VTi transmission|&quot;VTi&quot; CVT transmission]]&lt;br /&gt; [[w:Allison Transmission|Allison]] 3000, 4000, &amp; Torqmatic Series automatic transmissions||1992||2017 (left GM)&lt;br&gt;&lt;br&gt;2019 (production for GM ended)|| [[w:Adam Opel AG|Opel plant]]. Originally a joint venture between GM &amp; Hungarian truck and engine maker Raba. GM bought out Raba &amp; became 100% owner in 1995. Production of Allison Transmissions began in 2000. Sold to [[w:PSA Group|PSA Group]] in 2017. Szentgotthárd continued to supply the [[w:GM Medium Diesel engine|1.6L LH7 turbodiesel I4]] to GM through 2019. Part of [[w:Stellantis|Stellantis]] since 2021. 

|- 

|&amp;nbsp;||[[w:Opel Wien|Opel Wien GmbH]]||[[w:Aspern|Aspern]]||[[w:Austria|Austria]]||[[w:Family 0 engine|Family 0]] engines (1.0, 1.2, 1.4, 1.4 Turbo)&lt;br /&gt;Transmissions (Easytronic automated manual, F15/F17 five-speed manual and M20/M32 six-speed manual)||1982||2017|| [[w:Adam Opel AG|Opel plant]]. Sold to [[w:PSA Group|PSA Group]] in 2017. Part of [[w:Stellantis|Stellantis]] since 2021. Closed by Stellantis in 2024. &lt;br /&gt; Past engines: [[w:GM Family 1 engine|GM Family 1 engine]] SOHC versions.  

|- 

|&amp;nbsp;||Osaka Assembly (Built on land leased from [[w:Sojitz|Nihon Menka]])&lt;ref&gt;{{cite book|url=https://books.google.com/books?id=TY4l3qWIIh4C&amp;q=general+motors+assembly+plant+location+osaka+japan&amp;pg=PA70|title=American Multinationals and Japan: The Political Economy of Japanese Capital Controls, 1899-1980|author=Mark Mason|date=14 October 1992|publisher=Harvard Univ Asia Center|isbn=9780674026308|via=Google Books}}&lt;/ref&gt;||[[w:Osaka|Osaka]]||[[w:Japan|Japan]]||Chevrolet, Pontiac, Oldsmobile, Buick from CKD kits||1927||1941||Factory was seized by [[w:Imperial Japanese|Imperial Japanese]] Government, see also [[w:General Motors Japan|General Motors Japan]]&lt;ref&gt;{{cite web|url=http://www.autonews.com/article/20080914/ANA03/809150388/gm-had-early-start-in-japan-but-was-hobbled-by-nationalism|title=GM early history in Japan|author=Hans Greimel|publisher=Autonews.com|date=September 14, 2008}}&lt;/ref&gt;&lt;ref&gt;{{cite web|url=https://history.gmheritagecenter.com/wiki/index.php/File:1926-6-1.jpg|title=Image of Osaka facility}}&lt;/ref&gt; 

|- 

|&amp;nbsp;||[[w:Oshawa Truck Assembly|Oshawa Battery Plant]]||[[w:Oshawa, Ontario|Oshawa, Ontario]]||[[w:Canada|Canada]] ||Batteries||19?||1990's?||Was part of the overall Oshawa Assembly complex (Autoplex) on Park Road South. Referred to by Delco Remy as Plant 41. This operation was closed.

|- 

|9 (1917-Mid 1923 Chevrolet)||Oshawa North||[[w:Oshawa, Ontario|Oshawa, Ontario]]||[[w:Canada|Canada]]||&lt;br /&gt;||1907||1996||The original Oshawa (North) plant opened in 1907 as a McLaughlin Motor Car Co. plant. It produced McLaughlin-Buick cars by fitting Buick engines and chassis to McLaughlin bodies. It also built Chevrolets for Chevrolet Motor Co. beginning in 1915 as the Chevrolet Motor Car Co. of Canada. McLaughlin Motor Car Co. and the Chevrolet Motor Car Co. of Canada were bought out by GM in 1918 becoming GM of Canada. GM of Canada continued to make Chevrolets and McLaughlin-Buicks (which became simply Buick after WWII) and also assembled [[w:Oakland Motor Car Company|Oakland]] 1921-1930, [[w:Oldsmobile|Oldsmobile]] 1920-1942, 1946-1969, [[w:Marquette (automobile)#Buick brand|Marquette]] 1929-1930, [[w:Buick|Buick]] 1908-1942, 1951-1971, [[w:LaSalle (automobile)|LaSalle]] 1927-1930, 1932-1935, [[w:Cadillac|Cadillac]] 1923-1936. [[w:Pontiac (automobile)|Pontiac]] production in Oshawa began shortly after US production in 1926. From the 1950's into the 1980's, Canadian market full-size Pontiacs were built on Chevrolet chassis and were powered by Chevrolet engines and had model names different from US-market Pontiacs (Pathfinder, Strato Chief, Laurentian, and Parisienne). Car production shifted to the current Oshawa complex Car Assembly plant (South plant; also known as Autoplex beginning in the 1980's) which opened in 1953. [[w:Chevrolet|Chevrolet]] trucks were made beginning in 1919 and [[w:GMC (automobile)|GMC]] trucks were made beginning in 1923 before truck production shifted to the Oshawa Truck plant located next to the South car plant in 1965. Oshawa also produced 65 [[w:Samson Tractor#Trucks and a car|Samson trucks]] from 1920-1921. Oshawa also produced military vehicles and equipment during both WWI and WWII. Also, Maple Leaf trucks.  

Operations were gradually moved from the older North plant to the newer South plant. The North plant, by then known as the GM North Fabrication plant making metal and plastic parts, was sold to Peregrine, Inc. in 1996. It was then sold to ACSYS Technologies Inc. in 2001. Both companies continued to operate as an auto parts manufacturer supplying GM. ACSYS closed the plant in 2004. The North plant ended all operations in 2005 and the last of it was demolished by 2006. Much of the site of the North plant at 155 Division Street (Ritson Road North is on the other side) is now a Costco.  

|- 

|1||[[w:Oshawa Truck Assembly|Oshawa Truck Assembly]]||[[w:Oshawa, Ontario|Oshawa, Ontario]]||[[w:Canada|Canada]]||[[w:Chevrolet Silverado|Chevrolet Silverado]] (1999-2009)&lt;br /&gt;[[w:GMC Sierra|GMC Sierra]] (1988-2009)||1965||2009||Part of the overall Oshawa Assembly complex (Autoplex) on Park Road South. Truck plant was at 1100 Park Road South at the southern end of the Autoplex. Production ended May 14, 2009. Over 10 million vehicles were produced. Now the GM Canadian Technical Centre's (CTC) McLaughlin Advanced Technology Track. &lt;br /&gt;Past models: [[w:Chevrolet C/K|Chevrolet C/K]] (-1986, 1988-1998), [[w:GMC C/K|GMC C/K]] (-1986)

|- 

|&amp;nbsp;||[[w:Delphi Automotive Systems|Packard Electric]]&lt;br /&gt; Main complex||[[w:Warren, Ohio|Warren, Ohio]]||United States||Automotive wiring&lt;br&gt;Electric Motors||1932||1999||Packard Electric was acquired by GM in 1932. Located between Griswold St NE on the north side, Dana St NE on the south side, Paige Ave NE on the east side, and N. Park Ave on the west side. Some of the earliest Packard cars were built here before Packard Automobile split from Packard Electric in 1902. Plant 4, which opened in 1938, was originally used by GM's Sunlight Electrical Division, which made electric motors. GM had acquired the former Sunlight Electrical Manufacturing Co. in March 1933. On July 1, 1943, Sunlight Electrical Division merged into GM's Packard Electric Division. Sunlight motors were still made in Plant 4. Became part of GM's Delphi Automotive Systems subsidiary in 1995 as Delphi Packard Electric Systems. Spun off with Delphi in 1999. Closed in 2006. 

|-

|&amp;nbsp;||[[w:Delphi Automotive Systems|Packard Electric]]&lt;br /&gt; Plant# 41||[[w:Warren, Ohio|Warren, Ohio]]||United States||Automotive wiring||1947||1998||Packard Electric was acquired by GM in 1932. Located at 1554 Thomas Rd SE. Became part of GM's Delphi Automotive Systems subsidiary in 1995 as Delphi Packard Electric Systems. Closed in 1998. Sold in 2004 to Wetzel, Inc. Sold to Berk Enterprise, Inc. in 2009.  

|-

|&amp;nbsp;||[[w:Delphi Automotive Systems|Packard Electric]]&lt;br /&gt; North River Road complex||[[w:Bazetta Township, Ohio|Bazetta Township, Ohio]] and [[w:Howland Township, Trumbull County, Ohio|Howland Township, Ohio]]||United States||Automotive wiring||1955||1999||Packard Electric was acquired by GM in 1932. Located on North River Road and Larchmont Avenue NE. The plant is in Bazetta Township and extends across the border into Howland Township. The majority is in Bazetta Township. Became part of GM's Delphi Automotive Systems subsidiary in 1995 as Delphi Packard Electric Systems. Spun off with Delphi in 1999. Parts of the site have been closed and demolished and/or sold but Delphi successor Aptiv still operates part of the site at 1265 North River Road.

|- 

|&amp;nbsp;||[[w:Delphi Automotive Systems|Packard Electric]]&lt;br /&gt; Brookhaven Plant||[[w:Brookhaven, Mississippi|Brookhaven, Mississippi]]||United States||Automotive wiring||1977||1999||Packard Electric was acquired by GM in 1932. Located at 925 Industrial Park Road NE. Became part of GM's Delphi Automotive Systems subsidiary in 1995 as Delphi Packard Electric Systems. Spun off with Delphi in 1999. Delphi successor Aptiv still operates the Brookhaven plant.  

|-

|&amp;nbsp;||[[w:Delphi Automotive Systems|Packard Electric]]&lt;br /&gt; Clinton Plant||[[w:Clinton, Mississippi|Clinton, Mississippi]]||United States||Automotive wiring||1973||1999||Packard Electric was acquired by GM in 1932. Located at 1001 Industrial Park Dr. Became part of GM's Delphi Automotive Systems subsidiary in 1995 as Delphi Packard Electric Systems. Spun off with Delphi in 1999. One plant closed in 2006 and the second closed in 2009.  

|-

|&amp;nbsp;||[[w:Delphi Automotive Systems|Packard Electric]]&lt;br /&gt; Mexico||[[w:Ciudad Juárez|Ciudad Juárez]], [[w:Chihuahua (state)|Chihuahua]]||[[w:Mexico|Mexico]]||Automotive wiring||1978||1999||Originally established as Conductores y Componentes Eléctricos by the Packard Electric division of GM. Became part of GM's Delphi Automotive Systems subsidiary in 1995. Spun off with Delphi in 1999. Delphi successor Aptiv still operates the Mexican plants.

|-

|&amp;nbsp;||[[w:Delphi Automotive Systems|Packard Electric]]&lt;br /&gt; Ireland Ltd.||[[w:Tallaght|Tallaght]]||[[w:Republic of Ireland|Ireland]]||Wire harnesses||1975||1996||Located on Airton Road. Production and export of wiring harnesses from this plant allowed GM to import fully built-up vehicles into Ireland before Ireland fully removed its restrictions on importing fully built-up vehicles. Became part of GM's Delphi Automotive Systems subsidiary in 1995. Closed in 1996.

|- 

|&amp;nbsp;||GM Peninsular SA||[[w:Barcelona|Barcelona]]||[[w:Spain|Spain]]||[[w:Chevrolet|Chevrolet]] trucks||1932||1936|| Production ended due to Spanish Civil War. Liquidated around 1939.  

|- 

|&amp;nbsp;||GM del Peru||[[w:Lima|Lima]]||[[w:Peru|Peru]]||[[w:Chevrolet Bel Air|Chevrolet Bel Air]]&lt;br /&gt;[[w:Chevrolet Camaro (first generation)|Chevrolet Camaro]]&lt;br /&gt;[[w:Chevrolet Caprice|Chevrolet Caprice]]&lt;br /&gt;[[w:Chevrolet Chevelle|Chevrolet Chevelle]]/[[w:Chevrolet Malibu|Chevrolet Malibu]]&lt;br /&gt;[[w:Chevrolet Impala|Chevrolet Impala]]&lt;br /&gt;[[w:Opel Kadett|Opel Kadett]]&lt;br /&gt;[[w:Opel Rekord|Opel Rekord]]&lt;br /&gt;[[w:Vauxhall Victor|Vauxhall Victor]]||1945||1970|| 

|- 

|&amp;nbsp;||[[w:Pittsburgh Metal|Pittsburgh Metal]]||[[W:West Mifflin, Pennsylvania|West Mifflin, Pennsylvania]]||United States||Metal stamping||1949||2008||Located at 1451 Lebanon School Road. Originally part of [[w:Fisher Body|Fisher Body]] division. Demolished in 2011.  

|- 

|&amp;nbsp;||GM Polsce Sp. Zo.o.||[[w:Warsaw|Warsaw]]||[[w:Poland|Poland]]||[[w:Chevrolet|Chevrolet]] cars and trucks||1928||1930's||Was at 103 Wolska St. Closed during the Depression. 

|-

|P (1939-1988)||[[w:Pontiac Assembly|Pontiac Assembly]]/Pontiac Fiero Assembly||[[w:Pontiac, Michigan|Pontiac, Michigan]]||United States||In ex-Fisher Body plant (Pontiac Fiero Assembly):&lt;br /&gt; [[w:Pontiac Fiero|Pontiac Fiero]] (1984-1988)&lt;br /&gt;&lt;br /&gt;In Main plant (Pontiac Assembly) after reopening:&lt;br /&gt; [[w:GM G platform (RWD)|RWD G-bodies]]:&lt;br /&gt; [[w:Chevrolet Monte Carlo#Fourth generation (1981–1988)|Chevrolet Monte Carlo]] (1987-1988),&lt;br /&gt; [[w:Oldsmobile Cutlass Supreme#Fourth generation (1978–1988)|Oldsmobile Cutlass Supreme]] (1985-1987),&lt;br /&gt; [[w:Oldsmobile 442|Oldsmobile 442]] (1986-1987),&lt;br /&gt;[[w:Oldsmobile Cutlass Supreme#Fourth generation (1978–1988)|Oldsmobile Cutlass Supreme Classic]] (1988),&lt;br /&gt; [[w:Buick Regal#Second generation (1978)|Buick Regal]] (1985-1987)&lt;br /&gt;&lt;br /&gt;Also:&lt;br /&gt; Pontiac engines:&lt;br /&gt; [[w:Pontiac straight-8 engine|Pontiac straight-8 engine]]&lt;br /&gt;[[w:Pontiac V8 engine|Pontiac V8 engine]]&lt;br /&gt;[[w:Pontiac Trophy 4 engine|Pontiac Trophy 4 engine]]&lt;br /&gt;[[w:Iron Duke engine|Pontiac Iron Duke/Tech IV I4 engine]]||1927||1987 (Pontiac Assembly)/1988 (Pontiac Fiero Assembly)||This was Pontiac's home plant. Property runs from Walton Blvd. on the north to E. Montcalm St. on the south with Joslyn Ave. or for certain stretches, Highwood Blvd., on the east side and Price St. or further south, Baldwin Ave. and then N. Saginaw St., on the west side. Also known as Pontiac North to distinguish from GMC's multiple plants in Pontiac, MI. Within 90 days of ground being broken, vehicles were already being produced in Pontiac's new home plant in 1927. Final Assembly was Plant 8 of Pontiac's Assembly complex in Pontiac, Michigan. On March 14, 1962, Pontiac Assembly built the 75 millionth GM vehicle built in the US, a white 1962 Bonneville convertible. Idled in 1982 but reopened in January 1985 with bodies supplied by Flint Body Assembly. Closed in December 1987. Last vehicle built was a Buick Regal Grand National. Demolished in 1997. GM still has the Pontiac Redistribution Center on the northeast portion of this property at 1251 Joslyn Road at the intersection with E. Columbia Ave. The Pontiac Metal Center is another still active part of this property. GM still uses the eastern part of the property bordered by Joslyn Ave. on the east, E. Beverly Ave. on the north, E. Montcalm St. on the south, and N. Glenwood Ave. on the west. This area includes GM Performance and Racing Center at 900 N. Glenwood Ave. and the Propulsion Systems Pontiac Engineering Center at 800 N. Glenwood Ave. Pontiac's divisional HQ moved here in 1970 from the previous location at the former Oakland HQ on 196 Oakland Ave. (now Cesar E Chavez Ave.). Pontiac's divisional HQ at One Pontiac Plaza was about where the Propulsion Systems Engineering Center is now. [[w:Fisher Body|Fisher Body]] operated a plant on the site (Plant 17) from 1935-1982. This plant was connected to the final assembly plant by an enclosed bridge that ran over N. Saginaw St., that was used to transport the bodies from the Fisher Body plant, where bodies up to the firewall were built, to the Pontiac final assembly plant where the body was mated to the chassis and the front end, powertrain, &amp; interior were installed and the car was completed. This plant, located at 900 Baldwin Ave., was converted to build the [[w:Pontiac Fiero|Pontiac Fiero]], which it built from 1983-1988. Last Fiero built August 16, 1988. GM used it as a warehouse until 2009 (&quot;Pontiac Warehouse Operations&quot;). Prototyping work was also done there. Most of the Fiero plant was demolished in 2013 (from Kennett Rd. until just before the plant sign which is just past St. Louis Ave.). There used to be an overpass going over Baldwin Ave. to the parking lot on the other side of Baldwin but this was taken down after Fiero production ended. Pontiac engines were made in Plant 9 and Plant 18. Another engine plant was built in 1981 in the northern part of the property. It was originally called Plant 55, later renamed Plant 33. It was next to Plant 51, later renamed Plant 25, which did chassis parts and machining and later, engine machining. Engine production ended in 1993. Plant 9 was demolished in 1997 &amp; Plant 18 was demolished in 1998. Plants 25 &amp; 33 were demolished sometime between 2008 &amp; 2013. Some parts of the complex have been sold to U-Pull And Save Auto Parts, Dani’s Trucking, GFL Environmental, &amp; Bedrock Express. &lt;br /&gt;[[w:Pontiac Six|Pontiac Six]] (1927-1932, 1935-1940), Pontiac Series 302 V8 (1932), Pontiac Economy Eight (1933-1934), Pontiac Improved Eight (1935), Pontiac Deluxe Eight (1936-1940), [[w:Pontiac 2+2|Pontiac 2+2]] (1964-1967), [[w:Pontiac Bonneville|Pontiac Bonneville (B-body)]] (1958-80), [[w:Pontiac Bonneville#Seventh generation (1982–1986)|Pontiac Bonneville (G-body)]] (1982), [[w:Pontiac Can Am|Pontiac Can Am]] (1977) [[w:Pontiac Catalina|Pontiac Catalina]] (1959-1980), [[w:Pontiac Chieftain|Pontiac Chieftain]] (1949-1958), [[w:Pontiac Custom S|Pontiac Custom S]] (1969), [[w:Pontiac Executive|Pontiac Executive]] (1967-70), [[w:Pontiac Grand Am#1973–1975|Pontiac Grand Am (1973-75)]], [[w:Pontiac Grand Am#1978–1980|Pontiac Grand Am (1978-80)]], [[w:Pontiac Grand Prix|Pontiac Grand Prix (B-body)]] (1962-1968), [[w:Pontiac Grand Prix#Third generation (1969–1972)|Pontiac Grand Prix (G-body)]] (1969-1972), [[w:Pontiac Grand Prix|Pontiac Grand Prix (A-/G-body)]] (1973-1982), [[w:Pontiac Grand Safari|Pontiac Grand Safari]] (1971-1978), [[w:Pontiac Grand Ville|Pontiac Grand Ville]] (1971-75), [[w:Pontiac GTO|Pontiac GTO]] (1964-1973), [[w:Pontiac LeMans|Pontiac LeMans]] (1962-1981), [[w:Pontiac Safari|Pontiac Safari]] (1955-1957), [[w:Pontiac Star Chief|Pontiac Star Chief]] (1954-66), [[w:Pontiac Streamliner|Pontiac Streamliner]] (1941-51), [[w:Pontiac Tempest|Pontiac Tempest]] (1961-1970), [[w:Pontiac LeMans#1970|Pontiac T-37]] (1970-1971), [[w:Pontiac Torpedo|Pontiac Torpedo]] (1940-1948), [[w:Pontiac Ventura#1960–1970|Pontiac Ventura]] (1960-1961)

|- 

|V (1972-1990)&lt;br /&gt;&lt;br /&gt; P (Pre-1972)||Pontiac Central Assembly||[[w:Pontiac, Michigan|Pontiac, Michigan]]||United States|||[[w:Chevrolet AK Series|GMC C-Series/E-Series]]&lt;br /&gt;[[w:GMC New Design|GMC New Design]] (1947-1951, 1952-1954)&lt;br /&gt;[[w:GMC Blue Chip|GMC Blue Chip]] (1955-1959)&lt;br /&gt; [[w:Chevrolet C/K|GMC C/K]] (1960-1985)&lt;br /&gt;[[w:Chevrolet C/K|Chevrolet C/K]] (1967-1985)&lt;br /&gt; [[w:GMC Suburban|GMC Suburban]] (1937-1966)&lt;br /&gt;[[w:GMC Motorhome|GMC Motorhome/TransMode]] (1978)&lt;br /&gt; Buses ([[w:GM &quot;old-look&quot; transit bus|Yellow Coach/GM &quot;old-look&quot; transit bus]] (1940-1969), [[w:GM PD-4103|GM PD-4103]], [[w:PD-4501 Scenicruiser|PD-4501 Scenicruiser]], [[w:GM New Look bus|GM New Look bus]] (1960-1977), [[w:GM Buffalo bus|GM Buffalo bus]] (1966-1980), [[w:Rapid Transit Series|Rapid Transit Series (RTS)]] (1978-1987))&lt;br /&gt;Medium Duty Trucks &amp; Heavy Duty Trucks including:&lt;br /&gt;[[w:Chevrolet C/K (second generation)#Medium-duty trucks|Chevrolet C-Series medium-duty trucks]] (1967-1972)&lt;br /&gt;[[w:Chevrolet/GMC B series#GMC (1966–1970)|GMC E-Series medium-duty trucks]] (E4500/E5500/E6500) (1967-1968) [https://web.archive.org/web/20140109015322/https://www.gmheritagecenter.com/docs/gm-heritage-archive/historical-brochures/GMC/100_YR_GMC_HISTORY_MAR09.pdf] (page 30)&lt;br /&gt;[[w:Chevrolet C/K (second generation)#Medium-duty trucks|GMC C-Series medium-duty trucks]] (1969-1972)&lt;br /&gt;[[w:Chevrolet C/K (third generation)#Medium-duty trucks (1973–1989)|Chevrolet/GMC C-Series medium-duty trucks]] (1985-1990)&lt;br /&gt;[[w:Chevrolet Kodiak#First generation (1981–1989)|Chevrolet Kodiak]] (1985-1990)&lt;br /&gt;[[w:Chevrolet Kodiak#First generation (1981–1989)|GMC Top Kick]] (1985-1990)&lt;br /&gt;[[w:Chevrolet/GMC B series|Chevrolet B-series]] (-1991)&lt;br /&gt;[[w:Chevrolet/GMC B series|GMC B-series]] (-1991)&lt;br /&gt;[[w:GMC Brigadier#Background|Chevrolet/GMC H/J series]] (1966-1977)&lt;br /&gt;[[w:Chevrolet Bruin|Chevrolet Bruin]] (1978-1980)&lt;br /&gt;[[w:GMC Brigadier|GMC Brigadier]] (1978-1987)&lt;br /&gt;[[w:WhiteGMC Brigadier|WhiteGMC Brigadier]] (1988-1989)&lt;br /&gt;[[w:GMC General#Background|Chevrolet/GMC C/M series]] (1966-1976)&lt;br /&gt;[[w:Chevrolet Bison|Chevrolet Bison]] (1977-1980)&lt;br /&gt;[[w:GMC General|GMC General]] (1977-1987)&lt;br /&gt;[[w:GMC Astro#Background|GMC F/D series &quot;Crackerbox&quot;]] (1959-1968)&lt;br /&gt;[[w:Chevrolet Titan|Chevrolet Titan]] (1970-1980)&lt;br /&gt;[[w:GMC Astro|GMC Astro]] (1969-1987)&lt;br /&gt;Engines ([[w:GMC straight-6 engine|GMC straight-6 engine]] 1947-1962,&lt;br /&gt; [[w:GMC V6 engine|GMC V6 (1960-1973)/V12 (1960-1965) engine]],&lt;br&gt; [[w:GMC V8 engine#GMC engines|GMC 60° V8]] (1966-1972))||1928||1990||Located at 660 South Boulevard East. Known as GMC Truck &amp; Coach Division Plant 2 when built. Production of trucks began in January 1928. In 1925, General Motors Truck Corp., the parent of the GMC brand, merged with Yellow Cab Manufacturing Company (including its Yellow Coach Mfg. Co. bus-making subsidiary) to form Yellow Truck &amp; Coach Manufacturing Company, in which GM owned a majority stake of 57%. The Northway Motor Division of Detroit was transferred to General Motors Truck Corp. as part of that merger but was liquidated in 1926. On September 30, 1943, GM acquired the remainder of Yellow Truck &amp; Coach Manufacturing Co. and on October 1, 1943 the GMC Truck &amp; Coach Division of General Motors Corp. was formed and Yellow Truck &amp; Coach Manufacturing Co. was dissolved. When limited production of civilian buses resumed in March 1944, they were badged as GM Coach and the Yellow name was retired. Headquarters of Yellow Truck &amp; Coach Manufacturing Co. and later the GMC Truck &amp; Coach Division. Headquarters building in front of Plant 2 was completed in March 1928. Administration and engineering buildings were part of the complex. Built 409,012 [[w:GMC CCKW 2½-ton 6×6 truck|CCKW 6x6 trucks]], AFKWX 6x6 cab-over trucks, [[w:DUKW|DUKW &quot;Ducks&quot;]], &amp; other types of trucks during WWII. Also produced 2,249 buses &amp; 30 T18E2 Boarhound armored cars during WWII. The small-block, Group 1 GMC inline-6s were moved from Plant 4 of Pontiac West to Building 29 at Pontiac Central in November 1947. In December 1947, engine manufacturing and machine shops moved from Plants 1 and 4 of Pontiac West to Building 29 at Pontiac Central. The medium- and big-block, Group 2 &amp; 3 GMC inline-6s were moved to Building 29 at Pontiac Central in February 1948. In August 1977, the GMC MotorHome was moved from Plant 3 of Pontiac West to Building 29 at Pontiac Central. The GMC MotorHome was discontinued after 1978. [https://www.gmccolonial.com/gmc-motorhome-history] Transit bus production ended in spring 1987 when GM sold the product line to Greyhound Corporation, which continued RTS production at its [[w:Transportation Manufacturing Corporation|TMC]] plant in Roswell, New Mexico. Converted in 1994 into a Truck Product Engineering Center (Pontiac Centerpoint Campus) by GM using only the steel frame of the large main building while everything else was demolished. The Truck Product Engineering Center closed in 2009 and the site is now the Centerpoint Business Campus, which is occupied by many businesses including Fanuc Robotics and i.M. Branded.  

|- 

|E (1988-2009)&lt;br /&gt;&lt;br /&gt;V (1972-1985)||[[w:Pontiac East Assembly|Pontiac East Assembly]]||[[w:Pontiac, Michigan|Pontiac, Michigan]]||United States||Medium Duty Trucks:&lt;br /&gt; [[w:Chevrolet C/K (third generation)#Medium-duty trucks (1973–1989)|Chevrolet/GMC C-Series medium-duty trucks]] (1973-85), [[w:Chevrolet Kodiak#First generation (1981–1989)|Chevrolet Kodiak]] (1981-1985), [[w:Chevrolet Kodiak#First generation (1981–1989)|GMC Top Kick]] (1981-85)&lt;br /&gt;&lt;br /&gt; [[w:Chevrolet C/K (fourth generation)|Chevrolet C/K (GMT400)]] (1988-1998)&lt;br /&gt; [[w:Chevrolet C/K (fourth generation)|GMC Sierra (GMT400)]] (1988-1998)&lt;br /&gt; [[w:Chevrolet Silverado#First-generation Silverado / second-generation Sierra (GMT800; 1999)|Chevrolet Silverado (GMT800)]] (1999-2006)&lt;br /&gt; [[w:Chevrolet Silverado#First-generation Silverado / second-generation Sierra (GMT800; 1999)|Chevrolet Silverado Classic (GMT800)]] (2007)&lt;br /&gt; [[w:Chevrolet Silverado#First-generation Silverado / second-generation Sierra (GMT800; 1999)|GMC Sierra (GMT800)]] (1999-2006)&lt;br /&gt; [[w:Chevrolet Silverado#First-generation Silverado / second-generation Sierra (GMT800; 1999)|GMC Sierra Classic (GMT800)]] (2007)&lt;br /&gt; [[w:Chevrolet Silverado#Second-generation Silverado / third-generation Sierra (GMT900; 2007)|Chevrolet Silverado (GMT900)]] (2007-2009)&lt;br /&gt; [[w:Chevrolet Silverado#Second-generation Silverado / third-generation Sierra (GMT900; 2007)|GMC Sierra (GMT900)]] (2007-2009) ||1972||2009||Located at 2100 South Opdyke Road. Known as GMC Truck &amp; Coach Division Plant 6 when built, also known as Pontiac Assembly Center. Pontiac East is directly to the east of Pontiac Central. Pontiac East began by building medium-duty trucks, which were moved from Pontiac Central. In 1985, medium-duty trucks were moved back to Pontiac Central, combining with production of heavy-duty trucks and buses. GMT400 full-size pickup production began in December 1986 for the 1988 model year. Closed in September 2009. Demolished in 2011-2012. Portions of the site are now occupied by Challenge Manufacturing Co. and Williams International. 

|- 

|0 (1978-1994)&lt;br /&gt;&lt;br /&gt;V (1972-1977)&lt;br /&gt;&lt;br /&gt; P (Pre-1972)||[[w:Pontiac West Assembly|Pontiac West Assembly]]||[[w:Pontiac, Michigan|Pontiac, Michigan]]||United States||Trucks, Buses,&lt;br /&gt;Engines: ([[w:Buick straight-6 engine|Buick 257/331 straight-6 engine]] (1931-1932), [[w:GMC straight-6 engine|GMC straight-6 engine]] 1933-1948), &lt;br /&gt; [[w:GMC Motorhome|GMC Motorhome/TransMode]] (1973-1977)&lt;br /&gt; [[w:Chevrolet van#First generation (1964–1966)|Chevrolet Van/GMC Handi-Van]] (1964-1966)&lt;br /&gt;[[w:Chevrolet van#Second generation (1967–1970)|Chevrolet Van/GMC Handi-Van]] (1967-1970)&lt;br /&gt;[[w:Chevrolet van#Third generation (1971–1996)|Chevrolet Van/GMC Vandura]] (1978-1980)&lt;br /&gt;[[w:Chevrolet S-10#First generation (1982)|Chevrolet S-10]]&lt;br /&gt; (1982-1984, 1991-1993)&lt;br /&gt;[[w:GMC S-15|GMC S-15]] (1982-1984)&lt;br /&gt;[[w:GMC Sonoma|GMC Sonoma]] (1991-1993)&lt;br /&gt;[[w:Chevrolet S-10 Blazer#First generation (1983–1994)|Chevrolet S-10 Blazer]]&lt;br /&gt; (1983-1994 2-d, 1994 4-d)&lt;br /&gt;[[w:GMC S-15 Jimmy|GMC S-15 Jimmy]]&lt;br /&gt; (1983-1994 2-d, 1994 4-d)&lt;br /&gt;[[w:GMC Typhoon|GMC Typhoon]] (1992-1993)&lt;br /&gt;[[w:Oldsmobile Bravada#First generation (1991–1994)|Oldsmobile Bravada]] (1994) ||1906||1994||Complex includes GMC Truck &amp; Coach Division Plants 1, 3, 4, and 5. Plant 1 was originally the plant of Rapid Motor Vehicle Company, one of the 2 main ancestors of the modern GMC Division (the other being Reliance Motor Car Company). Plant 1 was located at 25 Rapid Street and opened in 1906, before Rapid was taken over by GM in 1908-1909. Plant 1 started making Buick 257 &amp; 331 inline-6's in 1931 after Buick stopped making inline-6s after 1930 and switched its entire lineup to straight-8s. The tooling was moved to Plant 1 from the Buick complex in Flint. Buick had been supplying inline-6s to GMC since 1925. In 1933, GMC started making inline-6s of its own design in Plant 1. The medium- and big-block, Group 2 &amp; 3 GMC inline-6s were moved to Building 29 at Pontiac Central in February 1948. Plant 1 was demolished around 1981. Plant 3 opened in 1940 and was located at South Boulevard West and Franklin Road. Plant 3 was used for sheet metal work and material storage at first. Plant 3 later built the [[w:GMC Motorhome|GMC Motorhome]]. In August 1977, the GMC MotorHome was moved from Plant 3 of Pontiac West to Building 29 at Pontiac Central for its final model year of 1978. Plant 3 was demolished around 2005. Plant 4 was located on South Saginaw Street (now Woodward Ave.) Engine production began in Plant 4 in October 1938. The [[w:GMC straight-6 engine|GMC straight-6 engine]] was built there through 1947/1948. Small-block, Group 1 GMC inline-6 engines were made in Plant 4 from October 1938. The small-block, Group 1 GMC inline-6s were moved to Building 29 at Pontiac Central in November 1947. In December 1947, engine manufacturing and machine shops moved from Plants 1 and 4 to Building 29 at Pontiac Central. Plant 4 was also used for material storage. Plant 4 also built the [[w:Chevrolet van|1964-1970 Chevrolet &amp; GMC full-size vans]]. Plant 4 was demolished around 2008. Plant 5 was located on Franklin Road, to the north of Plant 3. Plant 5 was demolished around 2005. After Pontiac Central opened in 1928, Pontiac West focused on machining and component manufacturing rather than vehicle assembly.[https://www.hagerty.com/media/automotive-history/a-gmc-motor-homecoming-50-years-on/] (Paragraph 4) There would be sporadic vehicle production at Pontiac West in the 1960's and 1970's (vans, motorhomes). In the 1980's, vehicle production increased as Pontiac West became one of GM's plants building compact pickups and SUVs. Production ended in 1994. Entire property sold to M1 Concourse in 2014. 

|- 

|&amp;nbsp;||Pontiac Foundry||[[w:Pontiac, Michigan|Pontiac, Michigan]]||United States||[[w:Casting|Iron castings]] of engine parts. ||1927||1987||Was part of GM's Central Foundry Division. Was Plant 6 of Pontiac's Assembly complex in Pontiac, Michigan. Demolished in 1995. A U.S. Postal Service distribution center now occupies the approximate area where the foundry used to be. 

|- 

|&amp;nbsp;||[[w:Regina Plant|Regina Plant]]||[[w:Regina, Saskatchewan|Regina, Saskatchewan]]||[[w:Canada|Canada]] 

|[[w:Chevrolet|Chevrolet]] cars &amp; trucks, Maple Leaf trucks, [[w:Pontiac (automobile)|Pontiac]], [[w:Oldsmobile|Oldsmobile]], [[w:Buick|Buick]] 

|1928||1941||Factory office building is located at 1102 8th Avenue while the factory building is behind the office building stretching down Winnipeg Street down to 6th Ave. Production began on Dec. 11, 1928. Production halted in August 1930, restarted in March 1931, then halted again a few months later in 1931. Production restarted in December 1937. In 1941, taken over by the [[w:Government of Canada|Government of Canada]] to produce munitions for World War II as Regina Industries Limited. Auto production never resumed and the property was used by the Canadian Department of National Defense until the mid-1960s. Sold to the Saskatchewan provincial govt. in 1967 and then the Regina city govt. in 1987. Was used by both public- and private-sector tenants. Damaged by a fire on May 3, 2017. In 2020, the City of Regina decommissioned the building and all the tenants were required to move out. Buildings are still standing and have been used by a variety of businesses and organizations. You can still see &quot;GMC&quot; carved in stone above the front entrance to the office building. Office building is designated a Heritage Inventory Property by city of Regina. A related building is down the block at 1260 8th Avenue at the corner of Toronto Street. After the factory closed in 1941, GM still used this building for its regional administrative and parts distribution operations until it moved in 1967.

|- 

|&amp;nbsp;||[[w:GMC (marque)#History|Reliance Motor Truck Co.]]||[[w:Owosso, Michigan|Owosso]], [[w:Michigan|Michigan]]||United States||Reliance trucks (1909-1912)&lt;br&gt; GMC trucks (heavy duty models) (1912-1913)||1909||1913||Plant was located on Michigan Ave. In late 1908, GM bought Reliance Motor Car Co. and reorganized it as Reliance Motor Truck Co. Reliance truck production moved here from Detroit in 1909. In February 1912, the GMC brand replaced the Reliance brand as well as the Rapid brand. In 1913, production was consolidated at the Rapid Street plant of the former Rapid Motor Vehicle Co. in Pontiac, Michigan and the Owosso plant was sold. Plant was later used by American Malleables and later by Mid-West Abrasive Co., a maker of sandpaper. Plant was later extended to S. Washington St.

|-

|&amp;nbsp;||Saab [[w:Gothenburg|Gothenburg]] Transmission||[[w:Gothenburg|Gothenburg]]||[[w:Sweden|Sweden]]||Pre-GM era:&lt;br /&gt;[[w:Saab two-stroke|Saab two-stroke]]&lt;br /&gt;GM era:&lt;br /&gt;Saab 99/900 manual transmission&lt;br /&gt;[[w:F35 transmission|F35 transmission]]&lt;br /&gt;[[w:GM F40 transmission|GM F40 transmission]] ||1989||2009||Saab plant. Opened in 1953. Engine production ended in 1968. 

GM bought 50% of [[w:Saab Automobile|Saab Automobile]] in 1989 &amp; the other 50% in 2000. Transmission production ended when the 1st gen. 9-5 ended production. GM sold [[w:Saab Automobile|Saab Automobile]] to [[w:Spyker Cars|Spyker Cars]] in February, 2010. 

|- 

|&amp;nbsp;||Saab [[w:Sodertalje|Sodertalje]] Engine||[[w:Sodertalje|Sodertalje]]||[[w:Sweden|Sweden]]||Pre-GM era:&lt;br /&gt;[[w:Saab B engine|Saab B engine]]&lt;br /&gt;GM era:&lt;br /&gt;[[w:Saab H engine|Saab H engine]] ||1989||2007||Saab plant.  Opened in 1972.   

GM bought 50% of [[w:Saab Automobile|Saab Automobile]] in 1989 &amp; the other 50% in 2000. Engine plant sold to [[w:Scania AB|Scania AB]] in 2007. GM sold [[w:Saab Automobile|Saab Automobile]] to [[w:Spyker Cars|Spyker Cars]] in February, 2010. 

|- 

|1,2,3,4,8||Saab [[w:Trollhättan Assembly|Trollhättan Assembly]]||[[w:Trollhättan|Trollhättan]]||[[w:Sweden|Sweden]]||Pre-GM era:&lt;br /&gt;[[w:Saab 92|Saab 92]]&lt;br /&gt;[[w:Saab 93|Saab 93]]&lt;br /&gt;[[w:Saab 95|Saab 95]]&lt;br /&gt;[[w:Saab 96|Saab 96]]&lt;br /&gt;[[w:Saab 99|Saab 99]]&lt;br /&gt;GM era:&lt;br /&gt;[[w:Saab 900|Saab 900]]&lt;br /&gt;[[w:Saab 9000|Saab 9000]]&lt;br /&gt;[[w:Saab 9-3|Saab 9-3]]&lt;br /&gt;[[w:Saab 9-5|Saab 9-5]]&lt;br /&gt;[[w:Cadillac BLS|Cadillac BLS]]||1989||2010||Saab plant. Opened in 1947. Also did engine (Saab two-stroke) &amp; transmission production until 1953 when it was relocated to the Gothenburg plant. 

GM bought 50% of [[w:Saab Automobile|Saab Automobile]] in 1989 &amp; the other 50% in 2000. Saab also built the 9-3 based BLS for Cadillac. The BLS was not sold in the US or Canada. GM sold [[w:Saab Automobile|Saab Automobile]] to [[w:Spyker Cars|Spyker Cars]] in February, 2010.  

|- 

|&amp;nbsp;||Saginaw Malleable Iron||[[w:Saginaw, Michigan|Saginaw, Michigan]]||United States||&amp;nbsp;||1919||2007|| Located at 77 W. Center St. Iron castings. HQ of Central Foundry Division. In 1919, Saginaw Malleable Iron and Central Foundry merged with the Jacox division into GM's Saginaw Products Company. In 1928, became the Saginaw Malleable Iron division of GM. Closed in 2007, demolished in 2010. Converted into a park.  

|- 

|&amp;nbsp;||Saginaw Nodular Iron||[[w:Saginaw, Michigan|Saginaw, Michigan]]||United States||Steering knuckles, crankshafts, disc brake caliper housings, exhaust manifolds, flywheels, differential carriers, clutch pressure plates||1967||1988|| Located at 2100 Veterans Memorial Parkway. Straddles the City of Saginaw-Buena Vista Township border. Iron castings. Closed in 1988. Later demolished. 

|- 

|&amp;nbsp;||Saginaw Parts||[[w:Saginaw, Michigan|Saginaw, Michigan]]||United States||&amp;nbsp;||1909||1983|| Located on corner of 6th &amp; Washington Avenues. Opened in 1907 to build the 1908 Rainier. Bought by GM in 1909 as part of its purchase of [[w:Rainier Motor Car Company|Rainier Motor Car Company]]. Reorganized into the [[w:Marquette (automobile)#Company|Marquette Motor Co.]] which still made Rainier brand cars through 1911 as well as parts for Welch and Welch-Detroit cars. In 1912, the Rainier brand was replaced by the Marquette brand, which was said to be a combination of the previous Rainier and Welch-Detroit brands. In February 1912, the company was renamed Peninsular Motor Co. Some late production cars seem to have been badged as Peninsular. All of those activities ended at the end of 1912. In 1917, during World War I, the plant was reopened and used to manufacture mortar shells for the US Ordnance Corps. In 1919, became part of the Saginaw Products Company with this plant becoming the Saginaw Products Company Motor Plant. From 1919-1922, the plant made [[w:Chevrolet Inline-4 engine#224|OHV I4]] engines for [[w:Chevrolet Series FB|Chevrolet Series FB]] and [[w:Oldsmobile Model 43|Oldsmobile Model 43A]]. It was then used as a warehouse. From 1935, it made all different types of auto parts and service parts as Chevrolet Saginaw Service Parts Plant or from 1969, Chevrolet Saginaw Parts Plant. Closed in 1983, demolished in 1984.  

|- 

|&amp;nbsp;||Saginaw Steering Gear - Plant 1||[[w:Saginaw, Michigan|Saginaw, Michigan]]||United States||Steering components||1910||1984||Located on 628 North Hamilton St. Originally founded as the Jackson, Church and Wilcox Company (Jacox) in 1906. Bought by GM in 1910. Became the Jackson-Church-Wilcox or Jacox division of GM. In 1919, the Jacox division merged with Saginaw Malleable Iron and Central Foundry into GM's Saginaw Products Company. Became the Saginaw Steering Gear Division in 1928. Closed in 1984. Sold in 1987 to Thomson Industries. Still operates today as Thomson Aerospace &amp; Defense, a brand of Linear Motion LLC, which is owned by the Umbra Group of Italy. 

|- 

|&amp;nbsp;||Saginaw Steering Gear - Plant 2||[[w:Saginaw, Michigan|Saginaw, Michigan]]||United States||Steering Gears, pump hoses||1941||2001||Located at 1400 Holmes Street. Affectionately known as &quot;The Gun Plant&quot;, it was built in 1941 when the division was contracted to build M1919 machine guns, and M1-Carbines for World War II. After the war, normal steering gear production continued until its closure in 2001. It was demolished in 2002. 

|- 

|&amp;nbsp;||Saginaw Steering Gear complex||[[w:Buena Vista Township, Michigan|Buena Vista Township, Michigan]]||United States|| Complete Hydraulic and Electric Power Steering Systems, Halfshafts, Intermediate Drive Shafts||1953||2010||Located at 3900 E. Holland Road. Former Saginaw Steering Gear Division of GM. Saginaw Steering Gear Division renamed Saginaw Division in 1985. Grouped under Delphi Automotive Systems in 1995. Plant 3 opened in 1953, Plant 4 opened in 1956. The sprawling Five-Plant complex (Plants 3-7), division Headquarters and large engineering center, were spun off with Delphi in 1999. GM repurchased the Delphi Steering division from bankrupt Delphi in 2009, renaming it Nexteer Automotive, and then sold the division to [[w:Pacific Century Motors|Pacific Century Motors]] in 2010. The former GM Division now operates as &quot;[[w:Nexteer Automotive|Nexteer Automotive]]&quot;, an independent company headquartered at the Saginaw site. Nexteer moved its headquarters to Auburn Hills in 2015.  

|- 

|&amp;nbsp;||Saginaw Steering Gear Overseas Corp.||[[w:Hendon|Hendon]], [[w:England|England]]||United Kingdom|| Steering columns, Steering column components (jacket &amp; bracket assemblies), Vacuum pumps, EGR valves||1970 (auto parts)||?||Located on Capitol Way in The Capitol Industrial Park.  Originally opened in 1924 as a vehicle assembly plant making Chevrolets (See listing for &quot;GM Ltd.&quot;). When Chevrolet production was moved to Luton in 1930, Hendon was used for parts distribution. Later, Frigidaire made appliances at Hendon. In 1970, Hendon began producing steering columns. In 1971, more automotive components began to be produced in place of Frigidaire appliances. In 1979, Hendon became aligned with Saginaw Steering Gear in the US. In 1980, GM sold the Hendon site for redevelopment but leased back an area for construction of a new plant for Saginaw Steering Gear. The new plant opened in 1981. In 1982, GM Ltd. was dissolved and the Hendon plant became part of Saginaw Steering Gear Overseas Corp., part of GM Overseas Corp.

|- 

|&amp;nbsp;||Saginaw Transmission||[[w:Saginaw, Michigan|Saginaw, Michigan]]||United States||Manual Transmissions, Brakes||1921||1999||Located at 2328 E. Genesee Ave. Built 1919–20 for the Michigan Crankshaft Company (originally founded as National Engineering Company), acquired by GM in 1921 and placed under Saginaw Products Company. In 1928, became the Saginaw Crankshaft Division of GM. Transferred to Chevrolet upon the dissolution of the Crankshaft Division in 1931 when crankshaft manufacturing was turned over to the car divisions. Made the &quot;Saginaw&quot; 3 and 4-Speed manual transmissions.  It was spun off as part of Delphi in 1999. The plant was sold to [[w:TRW Automotive|TRW Automotive]] in 2007. TRW used the plant to produces brake and suspension components (known as TRW Braking and Suspension). TRW closed this plant in 2014.  

|- 

|4||[[w:Scarborough Van Assembly|Scarborough Van Plant]]||[[w:Scarborough, Toronto|Scarborough]], [[w:Ontario|Ontario]]||[[w:Canada|Canada]]||[[w:Chevrolet Van#Third generation (1971–1996)|Chevrolet Van]] (1974-1993)&lt;br /&gt;[[w:GMC Vandura#Third generation (1971–1996)|GMC Vandura]] (1974-1993)&lt;br /&gt;[[w:Chevrolet Sportvan#Third generation (1971–1996)|Chevrolet Sportvan]] (1974-1993)&lt;br /&gt;[[w:GMC Vandura#Third generation (1971–1996)|GMC Rally Van]] (1974-1993)&lt;br /&gt;||1952&lt;br&gt;&lt;br&gt;1974 (Vehicle production)||1993||Located at 1901 Eglinton Avenue East. Originally a [[w:Frigidaire|Frigidaire]] home appliance plant through 1970. In 1960, production of automotive components was added. Production included radios, instrument clusters, horns, shock absorbers, and propshafts. After Frigidaire production ended in 1970, only auto parts were made and the plant name was changed from Frigidaire Products of Canada to Delco Canada. Auto parts production ended in 1973 and the plant was expanded and converted to build full-size vans and renamed Scarborough Van Plant. First van produced on May 23, 1974 (a 1974 Chevy Van 10). After van production began, plant was expanded 5 times over the years. Cutaway production was added for 1975, halted in 1978, and resumed in 1980. One millionth van produced in January 1986 (a GMC model). Closed on May 6, 1993 and operations moved to [[w:Flint Truck Assembly|Flint Truck Assembly]]. Scarborough produced 1,626,313 vans from 1974-1993. Plant demolished and now site of Eglinton Town Centre and Comstock Bus Garage at the southern end of the property.  

|- 


|&amp;nbsp;||[[w:Scripps-Booth|Scripps-Booth]]||[[w:Detroit, Michigan|Detroit]], [[w:Michigan|Michigan]]||United States||Scripps-Booth automobiles||1918||1922||Taken over by Chevrolet by the end of 1917 before Chevrolet was part of GM. When Chevrolet became part of GM, Scripps-Booth became part of GM as well. Scripps-Booth then adopted an Oakland chassis and a Northway six-cylinder engine, using parts from other GM divisions. However, a place could not be found for Scripps-Booth in GM's lineup, so GM closed it down in 1922.

|-

|8||[[w:Shreveport Operations|Shreveport Operations]]||[[w:Shreveport, Louisiana|Shreveport, Louisiana]]||United States||[[w:Chevrolet Colorado#First generation (2004)|Chevrolet Colorado]] (2004-2012)&lt;br /&gt;[[w:Chevrolet Colorado#First generation (2004)|GMC Canyon]] (2004-2012)&lt;br /&gt;[[w:Hummer H3|Hummer H3]] (2006-2010)&lt;br /&gt;[[w:Hummer H3#H3T|Hummer H3T]] (2009-2010)&lt;br /&gt;[[w:Chevrolet Colorado#Isuzu i-series|Isuzu i-series]] pickup (2006-2008)||1981||2012||Located at 7600 General Motors Blvd. General Motors Blvd. was renamed Antoine Blvd. in 2013. A portion of the complex is now used by Glovis America, a Hyundai Automotive Group subsidiary, for a vehicle logistics and processing center for Hyundai and Kia vehicles. &lt;br /&gt;Past models: &lt;br&gt; [[w:Chevrolet S-10 |Chevrolet S-10]] (1982-03), [[w:Chevrolet S-10 EV|Chevrolet S-10 EV]] (1997-1998),&lt;br /&gt; [[w:Chevrolet S-10 Blazer#First generation (1983–1994)|Chevrolet S-10 Blazer]] (1983-1991 2-d),&lt;br /&gt; [[w:GMC S-15|GMC S-15]] (1982-1990), [[w:GMC Sonoma|GMC Sonoma]] (1991-03), [[w:GMC Syclone|GMC Syclone]] (1991),&lt;br /&gt; [[w:Chevrolet S-10 Blazer#First generation (1983–1994)|GMC S-15 Jimmy]] (1983-1991 2-d),&lt;br /&gt; [[w:Isuzu Hombre|Isuzu Hombre]] (1996-'00) 

|- 

|A||[[w:General Motors South Africa|General Motors South Africa]] Darling Street &amp; Kempston Road plants||[[w:Port Elizabeth, South Africa|Port Elizabeth]]||[[w:South Africa|South Africa]]||[[w:Acadian (automobile)|Acadian]] (from CKD kits supplied from Oshawa and Willow Run)&lt;br /&gt;[[w:Beaumont (automobile)|Acadian Beaumont &amp; Beaumont]] (from CKD kits supplied from Oshawa 1966-69)&lt;br /&gt;[[w:Chevrolet Series AA Capitol|Chevrolet Series AA Capitol]]&lt;br /&gt;[[w:Chevrolet Series AB National|Chevrolet Series AB National]]&lt;br /&gt;[[w:Chevrolet Series AC International|Chevrolet Series AC International]]&lt;br /&gt;[[w:Chevrolet Series AD Universal|Chevrolet Series AD Universal]]&lt;br /&gt;[[w:Chevrolet Series AE Independence|Chevrolet Series AE Independence]]&lt;br /&gt;[[w:Chevrolet Series BA Confederate|Chevrolet Series BA Confederate]]&lt;br /&gt;[[w:Chevrolet Standard Six|Chevrolet Standard Six]]&lt;br /&gt;[[w:Chevrolet Series CA Eagle / Master|Chevrolet Series CA Eagle / Master]]&lt;br /&gt;[[w:Chevrolet Master|Chevrolet Master]]&lt;br /&gt;[[w:Opel Ascona#Export models|Chevrolet Ascona]]&lt;br /&gt;[[w:Chevrolet Caprice|Chevrolet Caprice]]&lt;br /&gt;[[w:Statesman (automobile)#HJ|Chevrolet Caprice Classic]]&lt;br /&gt;[[w:Chevrolet Constantia|Chevrolet Constantia]]&lt;br /&gt;[[w:Chevrolet Corvair|Chevrolet Corvair]] (from CKD kits supplied from Oshawa)&lt;br /&gt;[[w:Chevrolet Chevair|Chevrolet Chevair]]&lt;br /&gt;[[w:Chevrolet Chevelle|Chevrolet Chevelle]]/[[w:Chevrolet Malibu|Chevrolet Malibu]]&lt;br /&gt;[[w:Chevrolet Chevy II/Nova|Chevrolet Chevy II/Nova]]&lt;br /&gt; [[w:Chevrolet Nomad#South Africa production (GMSA)|Chevrolet Nomad]]&lt;br /&gt; [[w:Statesman (automobile)#HQ|Chevrolet De Ville]]&lt;br /&gt;[[w:Holden HK#South Africa|Chevrolet El Camino&lt;br /&gt;Chevrolet El Toro]]&lt;br /&gt;[[w:Chevrolet Impala|Chevrolet Impala]]&lt;br /&gt;[[w:Holden HK#South Africa|Chevrolet Kommando]]&lt;br /&gt;[[w:Chevrolet LUV|Chevrolet LUV]]&lt;br /&gt;[[w:Holden EK|Holden EK]]&lt;br /&gt;[[w:Holden EJ|Holden EJ]]&lt;br /&gt;[[w:Holden EH|Holden EH]]&lt;br /&gt;[[w:Holden HD|Holden HD]]&lt;br /&gt;[[w:Holden HR|Holden HR]]&lt;br /&gt;[[w:Holden Monaro#Export program|Holden Monaro (HT)/Chevrolet SS (HG)]]&lt;br /&gt;[[w:Pontiac Parisienne|Pontiac Parisienne]]&lt;br /&gt;[[w:Vauxhall Viva#South Africa|Chevrolet Firenza/1300/1900]]&lt;br /&gt;[[w:Opel Rekord Series D#ZA|Chevrolet 2500, 3800, 4100]]&lt;br /&gt;[[w:Opel Rekord Series E#Chevrolet Rekord|Chevrolet Rekord]]&lt;br /&gt;[[w:Opel Ascona#Ascona C (1981–1988)|Opel Ascona C]]&lt;br /&gt;[[w:Opel Kadett A|Opel Kadett A]]&lt;br /&gt;[[w:Opel Kadett B|Opel Kadett B]]&lt;br /&gt;[[w:Opel Kadett#Kadett D (1979–1984)|Opel Kadett D]]&lt;br /&gt;[[w:Opel Kadett#Kadett E (1984–1995)|Opel Kadett E/Monza]]&lt;br /&gt;[[w:Opel Astra#F|Opel Kadett F]]&lt;br /&gt;[[w:Opel Astra#G|Opel Astra G]]&lt;br /&gt;[[w:Opel Corsa#Corsa B (S93; 1993)|Opel Corsa B/Corsa Lite]]&lt;br /&gt;[[w:Opel Rekord|Opel Rekord]]&lt;br /&gt;[[w:Vauxhall Cresta|Vauxhall Cresta]]&lt;br /&gt;[[w:Vauxhall Velox|Vauxhall Velox]]&lt;br /&gt;[[w:Vauxhall Victor|Vauxhall Victor]]&lt;br /&gt;[[w:Vauxhall Viscount|Vauxhall Viscount]]&lt;br /&gt;[[w:Vauxhall Viva#Other markets|Vauxhall Viva]]&lt;br /&gt;[[w:Isuzu F-Series|Isuzu F-Series]]&lt;br /&gt;[[w:Isuzu N-Series|Isuzu N-Series]]&lt;br /&gt; [[w:Isuzu Faster|Isuzu KB]]&lt;br /&gt;[[w:Isuzu D-Max|Isuzu KB (D-Max based)]]&lt;br /&gt;||1926 (Darling Street)&lt;br /&gt;1928 (Kempston Road)||1929 (Darling Street)&lt;br /&gt;2017||Also assembled in the pre-WWII era: &lt;br /&gt;[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]]&lt;br /&gt;[[w:Oakland (automobile)|Oakland]]&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]]&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:LaSalle (automobile)|LaSalle]]&lt;br /&gt;[[w:Cadillac|Cadillac]]&lt;br /&gt;[[w:GMC (automobile)|GMC]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford]]&lt;br /&gt;[[w:Opel|Opel]]&lt;br /&gt;[[w:Frigidaire|Frigidaire]] appliances. 

Also built the [[w:Ranger (automobile)#South Africa|Ranger]]. 

 
GM sold the factory to Isuzu in 2017 and left the South African market. Isuzu consolidated its commercial truck production in the Struandale plant which already built Isuzu pickups and the Kempston Road plant ended production on Nov. 30, 2018. 

|- 

|4||[[w:General Motors South Africa|General Motors South Africa]] Struandale plant||[[w:Port Elizabeth, South Africa|Port Elizabeth]]||[[w:South Africa|South Africa]]||[[w:Chevrolet Spark#Africa|Chevrolet Spark (M300)]]&lt;br /&gt;[[w:Opel Corsa#Corsa C (X01; 2000)|Opel Corsa C]]&lt;br /&gt;[[w:Chevrolet Montana#South Africa|Opel Corsa Utility/Chevrolet Utility]]&lt;br /&gt;[[w:Hummer H3|Hummer H3]]&lt;br /&gt;[[w:Isuzu D-Max#Second generation (RT; 2011)|Isuzu KB]]&lt;br /&gt;||1996||2017||Struandale was originally a Ford plant opened in 1973 which GM South Africa bought during the time it was known as Delta Motor Corp. in 1994. 

 
GM sold the factory to Isuzu in 2017 and left the South African market. Struandale absorbed Isuzu pickup production beginning with the 2nd generation D-Max around 2013 &amp; Isuzu commercial truck ([[w:Isuzu F-Series|Isuzu F-Series]] &amp; [[w:Isuzu N-Series|Isuzu N-Series]]) production in Jan. 2019. Isuzu KB was renamed D-Max in South Africa in 2018, aligning with the rest of the world. 

|- 

|&amp;nbsp;||[[w:General Motors South Africa|General Motors South Africa]] Engine plant - Aloes||[[w:Port Elizabeth, South Africa|Port Elizabeth]]||[[w:South Africa|South Africa]]||[[w:Chevrolet 153 4-cylinder engine|Chevrolet 153 4-cylinder engine]]&lt;br /&gt;[[w:Chevrolet Turbo-Thrift engine|Chevrolet Turbo-Thrift inline-6]]&lt;br /&gt;[[w:Vauxhall Viva|Vauxhall Viva]] inline-4||1966||1999?||  

|- 

|C (1965-1982)&lt;br /&gt;&lt;br /&gt; U (1964 [[w:Chevrolet|Chevrolet]])&lt;br /&gt;&lt;br /&gt;S (1960-1964 [[w:Pontiac (automobile)|Pontiac]])&lt;br /&gt;&lt;br /&gt;C (1937-1964 [[w:Oldsmobile|Oldsmobile]] and 1936-1959 [[w:Pontiac (automobile)|Pontiac]])&lt;br /&gt;&lt;br /&gt;2 (1938-1964 &lt;br&gt; [[w:Buick|Buick]]) ||[[w:South Gate Assembly|South Gate Assembly]]||[[w:South Gate, California|South Gate, California]]||United States||[[w:Chevrolet Cavalier|Chevrolet Cavalier]] (1982) &lt;br /&gt; [[w:Cadillac Cimarron|Cadillac Cimarron]] (1982)||1936||1982|| Located at 2700 Tweedy Blvd. South Gate Assembly was the 1st GM multi-brand assembly plant, assembling Buick, Oldsmobile, and Pontiac models. The first finished cars were produced in May 1936. It was operated by GM's Southern California Division through 1943. Automobile production ended in Feb. 1942. During WWII, it produced the M5 and M5A1 Stuart tanks from July 1942-August 1943 in cooperation with Cadillac Division which held the contract to build the tank. It also provided a proof range for Army Ordnance to test various types of machine gun and cannon shells. Space was also provided for Army Ordnance to modify M4 medium tanks. Also built were gun shields and deck houses for the Navy. When M5A1 production ceased in August 1943, the plant was leased to Douglas Aircraft Co. until the end of the war for aircraft parts production. After the war ended, in 1945, Southgate &amp; Linden were both placed in a new division called the [[w:Buick-Oldsmobile-Pontiac Assembly Division|Buick-Oldsmobile-Pontiac Assembly Division]]. South Gate began making Chevrolet full-size cars for 1964. BOP Assembly Division became GM Assembly Division in 1965. South Gate was converted to build H-body small cars like the Vega for 1975 but the plant was switched back to full-size cars for 1977, building Chevy, Oldsmobile, &amp; Buick B-bodies. In 1979, South Gate Assembly became the second plant (the 1st was Linden, NJ in 1971) outside Cadillac's home plant in Detroit to assemble Cadillacs when it began to assemble C-body Cadillacs like the DeVille instead of Oldsmobile &amp; Buick B-bodies. The plant was then idled in March 1980. It was again switched to build small cars for 1982, this time the J-body. Slow sales and efforts to reduce air quality issues resulted in plant closure, with production ending on March 23, 1982. Plant demolished and site used for 3 new schools for L.A. School District and the South Gate Industrial and Business Park at the southern end of the property.&lt;br /&gt; Unibody B-O-P &quot;Y&quot;-body [[w:Buick Special#1961–1963|Buick Special]]/[[w:Buick Skylark#First generation (1961–1963)|Buick Skylark]] (1962-1963), [[w:Oldsmobile F-85#First generation (1961)|Oldsmobile F-85/&lt;br&gt; Cutlass]] (1962-1963), [[w:Pontiac Tempest#First generation (1961–1963)|Pontiac Tempest]]/[[w:Pontiac LeMans#First generation (1961–1963)|Pontiac LeMans]] (1962-1963) added to B-&amp; C-body mix 1961-63; replaced by [[w:General Motors B platform|Chevrolet B-body]] for 1964; [[w:GM H platform (RWD)|GM H platform (RWD)]]: [[w:Chevrolet Vega|Chevrolet Vega]] (1975), [[w:Chevrolet Monza|Chevrolet Monza]] (1975-1976), [[w:Pontiac Astre|Pontiac Astre]] (1975), [[w:Pontiac Sunbird#First generation (1976–1980)|Pontiac Sunbird]] (1976), [[w:Oldsmobile Starfire#Second generation (1975–1980)|Oldsmobile Starfire]] (H-body) (1976), [[w:Buick Skyhawk#First generation (1975–1980)|Buick Skyhawk]] (1976); [[w:Buick Centurion|Buick Centurion]] (1971-1973); [[w:Buick Century|Buick Century]] (1936-1942, 1954-1958); [[w:Buick Electra|Buick Electra]] (1959-1963); [[w:Buick Estate#1970|Buick Estate]] (1970-1973); [[w:Buick Invicta|Buick Invicta]] (1959-1962); [[w:Buick LeSabre|Buick LeSabre]] (1959-1974, 1977-1978); [[w:Buick Roadmaster|Buick Roadmaster]] (1947-1949, 1953-1958); [[w:Buick Special|Buick Special]] (1936-1958); [[w:Buick Super|Buick Super]] (1940-1958); [[w:Buick Wildcat|Buick Wildcat]] (1963-1970); [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1964-1974); [[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-1974, 1977-80); [[w:Chevrolet Impala|Chevrolet Impala]] (1964-1974, 1977-1980); [[w:Oldsmobile 88|Oldsmobile 88]] (1949-1970, 1977-1978); [[w:Oldsmobile 98|Oldsmobile 98]] (1941-63); [[w:Oldsmobile Jetstar I|Oldsmobile Jetstar I]] (1964-1965); [[w:Oldsmobile Starfire#First generation (1961–1966)|Oldsmobile Starfire]] (1961-1966); [[w:Pontiac 2+2|Pontiac 2+2]] (1964-1967); [[w:Pontiac Bonneville|Pontiac Bonneville]] (1958-1970, 1972-1973); [[w:Pontiac Catalina|Pontiac Catalina]] (1959-1973); [[w:Pontiac Chieftain|Pontiac Chieftain]] (1949-1953, 1955-1958); [[w:Pontiac Executive|Pontiac Executive]] (1967-1968); [[w:Pontiac Grand Prix|Pontiac Grand Prix]] (1962-68); [[w:Pontiac Star Chief|Pontiac Star Chief]] (1955-1958, 1960, 1962, 1966); [[w:Pontiac Ventura#1960–1970|Pontiac Ventura]] (1960-1961); [[w:Cadillac Deville#Fifth generation (1977–1984)|Cadillac Deville]] (1979-1980).  

|- 

|&amp;nbsp;||[[w:St. Catharines Components Plant|St. Catharines Components Plant]]||[[w:St. Catharines, Ontario|St. Catharines, Ontario]]||[[w:Canada|Canada]]||Engine components&lt;br /&gt;Transmissions&lt;br /&gt;Transmission components&lt;br /&gt;Starter motors&lt;br /&gt;Alternators&lt;br /&gt; Final drive assemblies&lt;br /&gt; Axles&lt;br /&gt;Steering wheels&lt;br /&gt;Steering gear&lt;br /&gt;Shock absorbers&lt;br /&gt;Brakes&lt;br /&gt;Bearings&lt;br /&gt;Horns&lt;br /&gt;Vehicle Radios&lt;br /&gt;Fractional horsepower motors for appliances||1929||2010||Was located at 285 Ontario Street. Originally McKinnon Dash and Metal Work Ltd., which opened this site in 1900. In 1917, the company was renamed McKinnon Industries, Ltd. Taken over by GM on March 29, 1929. In 1963, fractional horsepower motors for appliances were moved to the GM Diesel plant in London, Ontario. In 1964, vehicle radios, horns, and shocks were moved to the Scarborough plant followed by propshafts in 1966. In 1969, McKinnon Industries Ltd. was integrated into GM Canada rather than being a separate subsidiary. In 1990, the Axle Plant is officially renamed Components Plant. Permanently closed in 2010 as part of GM's restructuring plans. All operations were transferred to [[w:St. Catharines Engine Plant|St. Catharines Engine Plant]]. Some of the Components Plant was demolished in 2016 and the site will be re-developed for mixed-use residential and commercial development. 

|- 

|&amp;nbsp;||St. Catharines Foundry||[[w:St. Catharines, Ontario|St. Catharines, Ontario]]||[[w:Canada|Canada]]||[[w:Casting|Iron casting]] of engine parts||1952||1995|| Was located at 285 Ontario Street. Operated as part of GM subsidiary McKinnon Industries, Ltd. until 1969 when it became &quot;General Motors of Canada Limited, St. Catharines&quot;. Aligned with GM's Central Foundry Division in 1989.  

|- 

|S &lt;br /&gt;(1952 [[w:GMC (automobile)|GMC]] and 1953-1987)&lt;br /&gt;&lt;br /&gt;3 &lt;br /&gt;(1928-1952 [[w:Chevrolet|Chevrolet]])||[[w:St. Louis Truck Assembly|St. Louis Truck Assembly]]||[[w:St. Louis, Missouri|St. Louis, Missouri]]||United States ||[[w:Chevrolet C/K|Chevrolet C/K]] (1960-1986)&lt;br /&gt;[[w:Chevrolet C/K (third generation)|GMC C/K (Rounded Line)]] (1973-1986)&lt;br /&gt;[[w:Chevrolet C/K (third generation)#R/V-Series (1987–1991)|Chevrolet R/V]] (1987 only)&lt;br /&gt;[[w:Chevrolet C/K (third generation)#R/V-Series (1987–1991)|GMC R/V]] (1987 only)||1920&lt;ref&gt;{{cite web|url=https://www.autonews.com/article/20111031/CHEVY100/310319998/built-across-the-nation|author=James B. Treece|title=Built across the nation|publisher=Autonews.com|date=October 31, 2011}}&lt;/ref&gt;||1987||Located at 3809 N. Union Blvd. Chevrolet had previously licensed [[w:Gardner (automobile)|Gardner Buggy Co.]] to assemble its cars in St. Louis in 1915. That was replaced by Chevrolet's own St. Louis plant on Union Blvd. Built 149,135 [[w:GMC CCKW 2½-ton 6×6 truck|GMC CCKW 6x6 trucks]] &amp; 6,748 [[w:DUKW|DUKW]] amphibious vehicles during WWII. Was part of the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were gradually transferred to the GM Assembly Division which replaced the BOP Assembly Division in 1965. St. Louis Assembly joined the GM Assembly Division in 1971. Operated 3 assembly lines: car line, truck line, and the Corvette line. 695,214 Corvettes were built from 1954-1981 in the old Fisher Body Mill Building that had been used to assemble wooden bodies in earlier years and was converted to Corvette production. First 1954 Corvette was built in St. Louis on December 28, 1953. Last Corvette built in St. Louis was built July 31, 1981. Chevy Caprice &amp; Impala production ended on August 1,  1980 and the main car line closed down. Was a Truck and Bus Group plant from 1982, only making full-size pickups. Closed August 7, 1987. The second-to-last vehicle produced was a GMC R1500 regular cab, long bed pickup while the last vehicle produced was a Chevy pickup. The old Fisher Body Mill Building where Corvettes were built was demolished in 1992. Some of the main assembly facility was demolished and the remainder was renovated to become the Union Seventy Center. The remainder of the site, roughly 118 acres, was demolished and replaced with trees, grass, a pond, &amp; new access roads. Property is now the Union Seventy Center, an industrial warehouse and distribution campus used by several different tenants. &lt;br /&gt;[[w:Chevrolet Series 490|Chevrolet Series 490]]&lt;br /&gt; [[w:Chevrolet Superior|Chevrolet Superior]]&lt;br /&gt;[[w:Chevrolet Series AA Capitol|Chevrolet Series AA Capitol]]&lt;br /&gt;[[w:Chevrolet Series AB National|Chevrolet Series AB National]]&lt;br /&gt;[[w:Chevrolet Series AC International|Chevrolet Series AC International]]&lt;br /&gt;[[w:Chevrolet Series AD Universal|Chevrolet Series AD Universal]]&lt;br /&gt;[[w:Chevrolet Series AE Independence|Chevrolet Series AE Independence]]&lt;br /&gt;[[w:Chevrolet Series BA Confederate|Chevrolet Series BA Confederate]]&lt;br /&gt;[[w:Chevrolet Standard Six|Chevrolet Standard Six]]&lt;br /&gt;[[w:Chevrolet Series CA Eagle / Master|Chevrolet Series CA Eagle / Master]]&lt;br /&gt;[[w:Chevrolet Master|Chevrolet Master]], [[w:Chevrolet Deluxe|Chevrolet Deluxe]]&lt;br /&gt;[[w:Chevrolet Stylemaster|Chevrolet Stylemaster]], [[w:Chevrolet Fleetmaster|Chevrolet Fleetmaster]], &lt;br /&gt;[[w:Chevrolet 150|Chevrolet 150]] (1953-1957), [[w:Chevrolet 210|Chevrolet 210]] (1953-1957), [[w:Chevrolet AK Series|Chevrolet AK Series]], [[w:Chevrolet Advance Design|Chevrolet Advance Design]] (1947-1955), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1950-1970), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1958-1970), [[w:Chevrolet K5 Blazer#1969–1972|Chevrolet K5 Blazer]] (1969-1972), [[w:Chevrolet Corvair|Chevrolet Corvair Forward Control]] (1961-1965), [[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-1980), [[w:Chevrolet Corvette|Chevrolet Corvette]] (1954-1981), [[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958), [[w:Chevrolet El Camino#First generation (1959–1960)|Chevrolet El Camino]] (1959-1960), [[w:Chevrolet Impala|Chevrolet Impala]] (1958-1980), [[w:Chevrolet Nomad|Chevrolet Nomad]] (1955-1957), [[w:Chevrolet Suburban|Chevrolet Suburban]] (1956, 1959, 1963-1967), [[w:Chevrolet Task Force|Chevrolet Task Force]] (1955-1959), [[w:Chevrolet C/K (second generation)|GMC C/K (Action Line)]] (1967-1972), [[w:Chevrolet K5 Blazer#1969–1972|GMC Jimmy]] (1970-1972), [[w:GMC New Design|GMC New Design]] (1953-1954), [[w:GMC Suburban|GMC Suburban]] (1947-1955, 1967-1972)

|- 

|2||[[w:Sainte-Thérèse Assembly|Ste. Thérèse Assembly]]||[[w:Boisbriand, Quebec|Boisbriand, Quebec]]||[[w:Canada|Canada]]||[[w:Chevrolet Camaro (fourth generation)|Chevrolet Camaro]] (1993-2002)&lt;br /&gt;[[w:Pontiac Firebird#Fourth generation (1993–2002)|Pontiac Firebird]] (1993-2002)||1966||2002||Located at 2500 Boulevard De la Grande-Allée. &lt;br /&gt;Past models:&lt;br&gt; [[w:Chevrolet Celebrity|Chevrolet Celebrity]] (1987-90)&lt;br /&gt;[[w:Oldsmobile Cutlass Ciera|Oldsmobile Cutlass Ciera]] (1988-1991)&lt;br /&gt;[[w:Oldsmobile Cutlass#Fifth-generation (intermediate) 1978–1988|Oldsmobile Cutlass/Cutlass Supreme]] (1978-1987)&lt;br /&gt;[[w:Oldsmobile 442|Oldsmobile Cutlass 442]] (1979)&lt;br /&gt;[[w:Pontiac Bonneville#Seventh generation (1982–1986)|Pontiac Bonneville]] (1983-86)&lt;br /&gt;[[w:Pontiac Grand Prix#Fifth generation (1978–1987)|Pontiac Grand Prix]] (1978-1981, 1983-1987)&lt;br /&gt;[[w:Pontiac Grand Prix#1986|Pontiac Grand Prix 2+2]] (1986)&lt;br /&gt;[[w:Chevrolet Vega|Chevrolet Vega]] (1973-1974)&lt;br /&gt;[[w:Pontiac Astre|Pontiac Astre]] (1973-1974)&lt;br /&gt;[[w:Chevrolet Monza|Chevrolet Monza]] (1975-1977)&lt;br /&gt;[[w:Pontiac Sunbird#First generation (1976–1980)|Pontiac Sunbird]] (1977)&lt;br /&gt;[[w:Oldsmobile Starfire#Second generation (1975–1980)|Oldsmobile Starfire]] (1975-77)&lt;br /&gt;[[w:Buick Skyhawk#First generation (1975–1980)|Buick Skyhawk]] (1975-1977)&lt;br /&gt;[[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1967-1970)&lt;br /&gt;[[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1967-70)&lt;br /&gt;[[w:Chevrolet Impala|Chevrolet Impala]] (1967-1970)&lt;br /&gt;[[w:Chevrolet Caprice|Chevrolet Caprice]] (1967-1970)&lt;br /&gt;[[w:Pontiac Catalina|Pontiac Catalina]] (1970-1972)&lt;br /&gt; [[w:Pontiac Grand Ville|Pontiac Grand Ville]] (1971).  

Plant demolished and site re-developed as a commercial and residential site known as Faubourg Boisbriand and the Centre for Sports Excellence. 

|- 

|&amp;nbsp;||Strasbourg Transmission||[[w:Strasbourg|Strasbourg]]||[[w:France|France]]||[[w:GM 6L50 transmission|6L45/6L50]] 6-speed RWD automatic transmissions||1968||2013||Past products: [[w:GM 5L40-E transmission|5L40]], [[w:GM 4L30-E transmission|4L30]], [[w:Turbo-Hydramatic 180|TH180/3L30]] RWD automatic transmissions 

Also supplied 4-, 5-, &amp; 6-speed RWD auto. transmissions to [[w:BMW|BMW]].&lt;br /&gt; Also supplied 3-speed RWD auto. transmissions to Fiat, Peugeot ([[w:Peugeot 604|604]]), &amp; Rover ([[w:Rover SD1|SD1]]). 

Sold to Punch Metals International in 2013, which renamed the unit as Punch Powerglide Strasbourg.&lt;ref&gt;{{Cite web|url=https://gmauthority.com/blog/2012/12/general-motors-sells-strasbourg-plant-to-punch-metals-international/|title = General Motors Sells Strasbourg Plant to Punch Metals International|author=Alex Luft|publisher=GMAuthority.com|date = 22 December 2012}}&lt;/ref&gt; In 2014, Punch Powerglide Strasbourg began producing [[w:ZF 8HP transmission|8HP 8-speed automatic transmissions]] for [[w:ZF Friedrichshafen|ZF Friedrichshafen]] in addition to the GM 6L50 6-speed automatic transmission. In 2023, Punch Powerglide Strasbourg was renamed Dumarey Powerglide Strasbourg.

|- 

|&amp;nbsp;||General Motors Suisse AG||[[w:Biel|Biel]]||[[w:Switzerland|Switzerland]]||[[w:Chevrolet|Chevrolet]] 1936-1941, 1946-1968&lt;ref&gt;{{cite web|title=What's Wrong With This Picture? And What's Very Right With the Other Ones? They Do Things a Bit Differently In Switzerland|date=15 August 2020 |at=see 20th comment down from 8-15-20 5:59 pm|url=https://www.curbsideclassic.com/blog/qotd/whats-wrong-with-this-picture-and-whats-very-right-with-the-other-ones-they-do-things-a-bit-differently-in-switzerland/}}&lt;/ref&gt;&lt;br /&gt;[[w:Pontiac (automobile)|Pontiac]] 1937-1939, 1946-1959 (None produced in 1955-1956)&lt;br /&gt;[[w:Oldsmobile|Oldsmobile]] 1936-1940, 1947-1958&lt;br /&gt;[[w:Buick|Buick]] 1936-1940, 1946-1958&lt;br /&gt;[[w:LaSalle (automobile)|LaSalle]] 1936 &lt;br /&gt;[[w:Cadillac|Cadillac]] 1938-1940&lt;br /&gt;[[w:Opel|Opel]] 1936-1941, 1950-1975&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]] 1936-1940, 1946-1971&lt;br /&gt;[[w:Ranger (automobile)#Europe|Ranger]] 1970-1975  ||1936||1975|| First car off the line was a [[w:Buick Series 40|Buick Model 41]] on February 5, 1936. Other prewar cars built include the [[w:Buick Series 90|Buick Series 90]] &amp; [[w:Opel P4|Opel P4]]. GM rented the factory from the city council until they bought it on Feb. 20, 1947. Closed August 14, 1975. Last car was an [[w:Opel Rekord D|Opel Rekord D]]. A total of 329,864 cars were assembled. Regular as well as customized vehicles in small series were made like drawing vehicles for the [[w:Swiss Armed Forces|Swiss Armed Forces]]: An open 6-seater [[w:Chevrolet|Chevrolet]] Platform combined with an Opel 2.5L I-6 cylinder; after World War II those &quot;Swiss&quot; cars were also offered to the public as limousines. As well, GM produced luxury upgraded vehicles for the European market like the [[w:Opel Kapitän|Opel Kapitän]], [[w:Opel Rekord P1#Swiss assembly|Rekord]] &quot;Ascona Edition&quot;, and the Kadett-based [[w:Opel Kadett B#Opel Ascona (modified Kadett B assembled in Biel, Switzerland)|Opel Ascona 1700]] up to the early 1970s. The [[w:Ranger (automobile)#Europe|Ranger]] was invented by using [[w:Vauxhall Motors|Vauxhall]] structures on an [[w:Opel Rekord C|Opel Rekord C]] body. Also built the first generation [[w:Chevrolet Camaro (first generation)|Chevrolet Camaro]], [[w:Chevrolet Chevelle|Chevrolet Chevelle]], [[w:Chevrolet Chevy II / Nova|Chevrolet Chevy II / Nova]], &amp; the [[w:Chevrolet Corvair|Chevrolet Corvair]] (from CKD kits supplied from Oshawa). Also built the [[w:Vauxhall Victor|Vauxhall Victor]] and the special Victor Riviera as well as the [[w:Vauxhall Cresta|Vauxhall Cresta]] and [[w:Vauxhall Viscount|Vauxhall Viscount]]. Afterwards the plant was used as GM's European central spare parts warehouse until 1992. Most buildings still exist, they now house a [[w:Coop (Switzerland)|Coop]] mall. &amp;nbsp;  

|- 

|T||[[w:General Motors India|Talegaon]]||[[w:Talegaon|Talegaon]], [[w:Pune district|Pune district]], [[w:Maharashtra|Maharashtra]]||[[w:India|India]]||[[w:Chevrolet Spark|Chevrolet Spark]]&lt;br /&gt;[[w:Chevrolet Beat|Chevrolet Beat]]&lt;br /&gt;[[w:Chevrolet Sail#Second generation (2010)|Chevrolet Sail U-VA]] (hatchback)&lt;br /&gt;[[w:Chevrolet Sail|Chevrolet Sail]]||2008||2020||Part of [[w:General Motors India|GM India]]. Production began in September 2008. Closed December 24, 2020. Sold to [[w:Hyundai Motor India|Hyundai Motor India]] in January 2024.  

|- 

|T (1953-1996)&lt;br /&gt;&lt;br /&gt;2 (1928-1952 [[w:Chevrolet|Chevrolet]])||[[w:North Tarrytown Assembly|North Tarrytown Assembly]]||[[w:Sleepy Hollow, New York|North Tarrytown, New York]]||United States||Past models:&lt;br /&gt;[[w:Chevrolet 490|Chevrolet 490]]&lt;br /&gt;[[w:Chevrolet Superior|Chevrolet Superior]]&lt;br /&gt;[[w:Chevrolet Series AA Capitol|Chevrolet Series AA Capitol]]&lt;br /&gt;[[w:Chevrolet Series AB National|Chevrolet Series AB National]]&lt;br /&gt;[[w:Chevrolet Series AC International|Chevrolet Series AC International]]&lt;br /&gt;[[w:Chevrolet Series AD Universal|Chevrolet Series AD Universal]]&lt;br /&gt;[[w:Chevrolet Series AE Independence|Chevrolet Series AE Independence]]&lt;br /&gt;[[w:Chevrolet Series BA Confederate|Chevrolet Series BA Confederate]]&lt;br /&gt;[[w:Chevrolet Standard Six|Chevrolet Standard Six]]&lt;br /&gt;[[w:Chevrolet Series CA Eagle / Master|Chevrolet Series CA Eagle / Master]]&lt;br /&gt;[[w:Chevrolet Master|Chevrolet Master]]&lt;br /&gt;[[w:Chevrolet Deluxe|Chevrolet Deluxe]]&lt;br /&gt;[[w:Chevrolet Stylemaster|Chevrolet Stylemaster]]&lt;br /&gt; [[w:Chevrolet Fleetmaster|Chevrolet Fleetmaster]]&lt;br /&gt;[[w:Chevrolet AK Series|Chevrolet AK Series]]&lt;br /&gt;[[w:Chevrolet Advance Design|Chevrolet Advance Design]] (1947-1955)&lt;br /&gt;[[w:Chevrolet Task Force|Chevrolet Task Force]] (1955-1959) &lt;br /&gt;[[w:Chevrolet C/K (first generation)|Chevrolet C/K (Gen.1)]] (1960-1966)&lt;br /&gt;[[w:Chevrolet C/K (second generation)|Chevrolet C/K (Action Line)]] (1967-1972)&lt;br /&gt;[[w:Chevrolet 150|Chevrolet 150]] (1953-1957)&lt;br /&gt;[[w:Chevrolet 210|Chevrolet 210]] (1953-1957)&lt;br /&gt; [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1950-1974)&lt;br /&gt;[[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1958-1970)&lt;br /&gt;[[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-1974)&lt;br /&gt;[[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958)&lt;br /&gt;[[w:Chevrolet Impala|Chevrolet Impala]] (1958-1974)&lt;br /&gt;[[w:Chevrolet Nomad|Chevrolet Nomad]] (1955-1957)&lt;br /&gt;[[w:Chevrolet Suburban|Chevrolet Suburban]] (1950, 1952, 1963-1964, 1966)&lt;br /&gt;[[w:Chevrolet C/K (second generation)|GMC C/K (Action Line)]] (1967-1972)&lt;br /&gt;[[w:Chevrolet Nova|Chevrolet Nova]] (1975-1979)&lt;br /&gt;[[w:Chevrolet Citation|Chevrolet Citation]] (1980-1985)&lt;br /&gt;[[w:Pontiac Ventura#1971–1977|Pontiac Ventura]] (1975-1977)&lt;br /&gt;[[w:Pontiac Phoenix#First generation (1977–1979)|Pontiac Phoenix (rwd X-body)]] (1978-1979)&lt;br /&gt;[[w:Pontiac Phoenix#Second generation (1980–1984)|Pontiac Phoenix (fwd X-body)]] (1980-1984)&lt;br /&gt;[[w:Pontiac 6000|Pontiac 6000]] (1985-1989)&lt;br /&gt;[[w:Buick Skylark#Fourth generation (1975–1979)|Buick Skylark (rwd X-body)]] (1976-1979)&lt;br /&gt;[[w:Buick Skylark#Fifth generation (1980–1985)|Buick Skylark (fwd X-body)]] (1980-1983)&lt;br /&gt;[[w:Buick Century#Fifth generation (1982–1996)|Buick Century]] (1985-1989)&lt;br /&gt;[[w:Chevrolet Lumina APV|Chevrolet Lumina APV]] (1990-1993)&lt;br /&gt;[[w:Chevrolet Lumina Minivan|Chevrolet Lumina Minivan]] (1994-1996)&lt;br /&gt;[[w:Pontiac Trans Sport#First generation (1990-1996)|Pontiac Trans Sport]] (1990-1996)&lt;br /&gt;[[w:Oldsmobile Silhouette#First generation (1990–1996)|Oldsmobile Silhouette]] (1990-1996) ||1918 (as part of GM)||1996|| Located at 199 Beekman Avenue. Originally built by [[w:Mobile Company of America|Mobile Company of America]]. In 1904, plant was sold to Maxwell-Briscoe, which later became [[w:Maxwell Motor Company|Maxwell Motor Company]]. Chevrolet bought the complex in 1914, before Chevrolet was part of GM. The first Chevrolet produced in Tarrytown was the [[w:Chevrolet 490|Chevrolet 490]]. The plant became part of GM when Chevrolet became part of GM in 1918. The Fisher Body side of the plant became part of GM's Eastern Aircraft Division during World War II and assembled the wings, center section, trailing edges, motor mount, cabin, windshield, &amp; upholstery for Avenger bombers &amp; Wildcat fighters. Built the 50 millionth Chevrolet, a white 1963 Impala SS on June 10, 1963. Was part of the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were gradually transferred to the GM Assembly Division which replaced the BOP Assembly Division in 1965. Tarrytown Assembly joined the GM Assembly Division in 1968. Passenger car production ended on Feb. 3, 1989. Plant joined Truck and Bus Group for 1990 when it was converted to build GM's new trio of fwd minivans. Plant closed in June 1996. Minivan production moved to [[w:Doraville Assembly|Doraville Assembly]] for 1997. North Tarrytown changed its name to Sleepy Hollow in December 1996. Plant was demolished. Site being redeveloped as Edge-on-Hudson, a mixed use residential/retail/office/park space.  

|-

|H||[[w:General Motors Thailand|General Motors Thailand]] Ltd.||Pluak Daeng, [[w:Rayong province|Rayong province]]||[[w:Thailand|Thailand]]||[[w:Chevrolet Colorado|Chevrolet/Holden Colorado]] (RC/RG) &lt;br /&gt; [[w:Chevrolet Trailblazer (SUV)#RG|Chevrolet/Holden Trailblazer &amp; Holden Colorado 7]] (RG)&lt;br /&gt;[[w:Chevrolet Cruze|Chevrolet Cruze]]&lt;br /&gt;[[w:Daewoo Lacetti|Chevrolet Optra]]&lt;br /&gt; [[w:Daewoo Kalos|Chevrolet Aveo]]&lt;br /&gt; [[w:Daewoo Winstorm|Chevrolet/Holden Captiva]]||2000||2020||Past Models:&lt;br /&gt; [[w:Opel Zafira#Zafira A (1999)|Opel/Vauxhall/Chevrolet Zafira]]&lt;br /&gt; [[w:Opel Zafira#Zafira A (1999)|Holden Zafira (TT)]]&lt;br /&gt; [[w:Subaru Traviq|Subaru Traviq]], [[w:Isuzu D-Max#First generation (RA, RC; 2002)|Isuzu D-Max]],&lt;br&gt; [[w:Alfa Romeo 156|Alfa Romeo 156]] [https://www.just-auto.com/news/thailand-gm-to-make-alfa-156-in-thailand/]&lt;br /&gt; Sold to [[w:Great Wall Motors|Great Wall Motors]] in 2020.&lt;ref&gt;{{Cite web|url=https://gmauthority.com/blog/2020/09/sale-of-gm-rayong-plant-to-great-wall-motors-confirmed/|title=Sale of GM Rayong Plant to Great Wall Motors Confirmed|author=Sam McEachern|publisher=GMAuthority.com|date=30 September 2020}}&lt;/ref&gt; 

|- 

|&amp;nbsp;||[[w:General Motors Thailand|General Motors Powertrain (Thailand) Ltd.]]||Pluak Daeng, [[w:Rayong province|Rayong province]]||[[w:Thailand|Thailand]]||2.5L ([[w:List of VM Motori engines#R 425 DOHC|R 425 DOHC]]) &amp; 2.8L ([[w:List of VM Motori engines#R 428 DOHC|R 428 DOHC]] &amp; [[w:List of VM Motori engines#A 428 DOHC|A 428 DOHC]]) turbodiesel I4 engines||2011||2020|| Sold to [[w:Great Wall Motors|Great Wall Motors]] in 2020.&lt;ref&gt;{{Cite web|url=https://gmauthority.com/blog/2020/09/sale-of-gm-rayong-plant-to-great-wall-motors-confirmed/|title=Sale of GM Rayong Plant to Great Wall Motors Confirmed|author=Sam McEachern|publisher=GMAuthority.com|date=30 September 2020}}&lt;/ref&gt; 

|-  

|&amp;nbsp;||Three Rivers||[[w:Three Rivers, Michigan|Three Rivers]], [[w:Michigan|Michigan]]||United States||Rwd Automatic transmissions, propshafts||1979||1994||Located at 1 Manufacturing Way (formerly 1 Hydramatic Drive) off W. Hoffman St. GM bought the closed plant from Continental Can Co. Part of GM St. Joseph County Operations &amp; GM Hydramatic Division. The Hydramatic Division merged with the GM Engine Division to form GM Powertrain in 1991-1992. Sold to [[w:American Axle|American Axle &amp; Manufacturing Inc.]] in 1994. 

|- 

|&amp;nbsp;||[[w:Toledo Transmission|Toledo Transmission]]||[[w:Toledo, Ohio|Toledo, Ohio]]||United States||Transmissions, Gears||1916||1957||Located at 900 W. Central Ave. Acquired from Warner Gear Co. by Chevrolet in 1916 before Chevrolet was part of GM. The plant became part of GM when Chevrolet became part of GM in 1918. During WWII, produced truck transfer cases and transmissions for four- and six-wheel-drive military trucks. Replaced by the current Toledo Transmission plant on Alexis Road in 1956. A brick smokestack that says &quot;CHEVROLET&quot; on it is a remnant of this plant and can still be seen today at the intersection of Maplewood Ave. and Arcadia Ave. It is similar to the more famous smokestack that says &quot;OVERLAND&quot;, a remnant of the old Willys-Overland Jeep plant, which is only a short distance away from the Chevrolet smokestack. 

|- 

|M||Toluca Assembly||[[w:Toluca|Toluca]]||[[w:Mexico|Mexico]]||[[w:Chevrolet Kodiak|Chevrolet Kodiak]]||1995&lt;ref&gt;{{cite news|author=Thomas H. Klier, James Rubenstein|title=Mexico’s Growing Role in the Auto Industry Under NAFTA: Who Makes What and What Goes Where|url=https://www.chicagofed.org/publications/economic-perspectives/2017/6.|publisher=Federal Reserve Bank of Chicago, Economic Perspectives, Vol. 41, No. 6|at=see table 11 and footnotes right under table 11|date=September 2017}}&lt;/ref&gt;||2008||[[w:Chevrolet C/K|Chevrolet C/K]], [[w:Chevrolet C/K (fourth generation)#C3500HD (1991–2002)|Chevrolet/GMC C3500HD]] (US: 2001-2002), [[w:Chevrolet Silverado#First-generation Silverado / second-generation Sierra (GMT800; 1999)|Chevrolet Silverado]] 

|- 

|&amp;nbsp;||Tonawanda Forge||[[w:Tonawanda (town), New York|Tonawanda]], [[w:New York (state)|New York]]||United States||Forged metal components||c.1950||1994||Located at 2390-2392 Kenmore Ave. Sold to [[w:American Axle|American Axle &amp; Manufacturing Inc.]] in 1994. Closed in 2008, subsequently demolished.  

|- 

|&amp;nbsp;||Tonawanda Foundry||[[w:Tonawanda (town), New York|Tonawanda]], [[w:New York (state)|New York]]||United States||[[w:Casting|Iron castings]] of engine parts, brake drums. ||1954||1984||Was located on River Road. Was a Chevrolet Foundry. Was part of GM's Central Foundry Division. &amp;nbsp; 

|- 

|Z||General Motors Turkiye Ltd.||[[w:Torbali|Torbali]], [[w:Izmir Province|Izmir Province]]||[[w:Turkey|Turkey]]||[[w:Opel Vectra|Opel Vectra]] A &amp; B||1990||2000||[[w:Adam Opel AG|Opel plant]]. Converted into a spare parts warehouse. 

|- 

|&amp;nbsp;||[[w:Ultium#Production|Ultium Cells LLC - Lansing]]||[[w:Delta Township, Michigan|Delta Township, Michigan]]||United States||Was supposed to make Ultium lithium-ion battery cells for EV's||Was scheduled to open in late 2024 or in 2025|| || Originally owned and constructed by Ultium Cells LLC, a 50/50 joint venture between General Motors and [[w:LG Energy Solution|LG Energy Solution]]. This was supposed to be Ultium Cells' third plant but GM sold its stake in the plant to partner LG Energy Solution in 2025 before the plant opened. Located at 7111 Davis Hwy. It is adjacent to GM's Lansing Delta Township Assembly plant.

|- 

|&amp;nbsp;||General Motors Uruguaya SA||[[w:Sayago|Sayago]], [[w:Montevideo|Montevideo]]||[[w:Uruguay|Uruguay]]||[[w:Chevrolet|Chevrolet]]&lt;br /&gt;[[w:Opel Kadett|Opel Kadett]]&lt;br /&gt;[[w:Opel Rekord|Opel Rekord]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford trucks]]||1962||1986||  

|- 

|L (1953-1992)&lt;br /&gt;&lt;br /&gt;20 (1947-1952 [[w:Chevrolet|Chevrolet]])||[[w:Van Nuys Assembly|Van Nuys Assembly]]||[[w:Van Nuys, California|Van Nuys, California]]||United States||[[w:Chevrolet Camaro|Chevrolet Camaro]] (1967-1971, 1978-1992)&lt;br /&gt;[[w:Pontiac Firebird|Pontiac Firebird]] (1968-1971, 1978-1992) ||1947||1992||Located at 8000 Van Nuys Blvd. Was part of the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were gradually transferred to the GM Assembly Division which replaced the BOP Assembly Division in 1965. Van Nuys Assembly joined the GM Assembly Division in 1968. Demolished in 1993. Redeveloped into &quot;The Plant&quot;, a retail and industrial complex that also includes LAPD and LAFD stations.&lt;br /&gt;Past models: [[w:Buick Apollo|Buick Apollo]] (1973-1975), [[w:Buick Skylark#Fourth generation (1975–1979)|Buick Skylark]] (1975-1977), [[w:Chevrolet 150|Chevrolet 150]] (1953-1957), [[w:Chevrolet 210|Chevrolet 210]] (1953-1957), [[w:Chevrolet Advance Design|Chevrolet Advance Design]] (1948-1955), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1950-1969), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1958-1969), [[w:Chevrolet C/K (first generation)|Chevrolet C/K]] (1960-1966), [[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-1969), [[w:Chevrolet Chevelle|Chevrolet Chevelle]] (1964, 1970-1972), [[w:Chevrolet Corvair|Chevrolet Corvair]] (1963, 1965-1966), [[w:Chevrolet Delray|Chevrolet Delray]] (1954-1958), [[w:Chevrolet El Camino|Chevrolet El Camino]] (1959-1960, 1964, 1970-1972), [[w:Chevrolet Impala|Chevrolet Impala]] (1958-1969), [[w:Chevrolet Monte Carlo|Chevrolet Monte Carlo]] (1970-1972), [[w:Chevrolet Nomad|Chevrolet Nomad]] (1955-1957), [[w:Chevrolet Nova|Chevrolet Nova]] (1972-1977), [[w:Chevrolet Suburban|Chevrolet Suburban]] (1952, 1955, 1959), [[w:Chevrolet Task Force|Chevrolet Task Force]] (1955-1959), [[w:GMC Sprint|GMC Sprint]] (1971-1972), [[w:Oldsmobile Omega|Oldsmobile Omega]] (1973-1977), [[w:Pontiac GTO#Fourth generation|Pontiac GTO]] (1974), [[w:Pontiac Ventura#1971–1977 X-body compact|Pontiac Ventura]] (1972-1976)

|- 

|&amp;nbsp;||Vauxhall - Bedford Die Plant||[[w:Bedford|Bedford]], [[w:Bedfordshire|Bedfordshire]]||[[w:United Kingdom|United Kingdom]]||Tools &amp; Die Manufacturing||1969||1980's||Opened May 1969. Supplemented die-making at the Luton plant. 

|-

|8 (since 1993)&lt;br /&gt;E (before 1993)||[[w:Vauxhall Ellesmere Port|Vauxhall Ellesmere Port]]||[[w:Ellesmere Port|Ellesmere Port]], [[w:Cheshire|Cheshire]]||[[w:United Kingdom|United Kingdom]]||[[w:Opel Astra#K|Opel]]/[[w:Vauxhall Astra|Vauxhall Astra]] K (5-door, Sports Tourer)&lt;br /&gt;[[w:Opel Astra#J|Opel]]/[[w:Vauxhall Astra|Vauxhall Astra]] J (5-door, Sports Tourer)&lt;br /&gt;[[w:Opel Astra#H|Opel]]/[[w:Vauxhall Astra|Vauxhall Astra]] H&lt;br /&gt;[[w:Opel Astra#G|Opel]]/[[w:Vauxhall Astra|Vauxhall Astra]] G&lt;br /&gt;[[w:Opel Astra#F|Opel]]/[[w:Vauxhall Astra|Vauxhall Astra]] F&lt;br /&gt;[[w:Opel Kadett E|Opel Kadett E]]/[[w:Vauxhall Astra#Second generation (1984–1991)|Vauxhall Astra Mk II]]&lt;br /&gt;[[w:Vauxhall Belmont|Vauxhall Belmont]]&lt;br /&gt;[[w:Opel Combo#Kadett Combo (Combo A; 1986)|Opel Kadett Combo/Bedford Astravan &amp; Astramax]]&lt;br /&gt;[[w:Vauxhall Astra#First generation (1980–1984)|Vauxhall Astra Mk I]]&lt;br /&gt;[[w:Vauxhall Chevette|Vauxhall Chevette]]&lt;br /&gt;[[w:Bedford Chevanne|Bedford Chevanne]]&lt;br /&gt;[[w:Vauxhall Firenza|Vauxhall Firenza]]&lt;br /&gt;[[w:Vauxhall Magnum|Vauxhall Magnum]]&lt;br /&gt;[[w:Opel Vectra#Vectra C (2002–2010)|Opel/Vauxhall Vectra C]]&lt;br /&gt;[[w:Vauxhall Viva|Vauxhall Viva]]&lt;br /&gt;[[w:Holden Astra#Third generation (TR; 1995)|Holden Astra (TR)]]&lt;br /&gt;[[w:Holden Astra#Seventh generation (BK, BL; 2016)|Holden Astra (BK)]] (wagon)&lt;br /&gt;Vauxhall Viva OHV Inline-4&lt;br /&gt;[[w:General Motors 54° V6 engine|General Motors 54° V6 engine]]||1962||2017|| [[w:Vauxhall Motors|Vauxhall plant]]. &lt;br /&gt;Also made engines, transmissions, axles, &amp; other components. Component production began in November 1962. Vehicle production began with the Viva on June 1, 1964. Engine production ended in 2004. Sold to [[w:PSA Group|PSA Group]] in 2017. Part of [[w:Stellantis|Stellantis]] since 2021. Absorbing production of electric midsize vans from Luton van plant following Luton's closure on March 28, 2025.

|- 

|7 (since 1993)&lt;br /&gt;V (before 1993)||Vauxhall Luton (car plant)||[[w:Luton|Luton]], [[w:Bedfordshire|Bedfordshire]]||[[w:United Kingdom|United Kingdom]]||[[w:Vauxhall Carlton|Vauxhall Carlton]]&lt;br /&gt;[[w:Vauxhall Cavalier|Vauxhall Cavalier]]&lt;br /&gt;[[w:Vauxhall Cresta|Vauxhall Cresta]]&lt;br /&gt;[[w:Opel Vectra#Vectra A (1988–1995)|Opel Vectra A]]&lt;br /&gt;[[w:Opel Vectra#Vectra B (1995–2002)|Opel/Vauxhall Vectra B]]&lt;br /&gt;[[w:Vauxhall Velox|Vauxhall Velox]]&lt;br /&gt;[[w:Vauxhall Ventora|Vauxhall Ventora]]&lt;br /&gt;[[w:Vauxhall Victor|Vauxhall Victor]]&lt;br /&gt;[[w:Vauxhall Viscount|Vauxhall Viscount]]&lt;br /&gt;[[w:Vauxhall Viva|Vauxhall Viva]]&lt;br /&gt;[[w:Vauxhall VX4/90|Vauxhall VX4/90]]&lt;br /&gt;[[w:Vauxhall VX Series|Vauxhall VX Series]]&lt;br /&gt;[[w:Vauxhall Wyvern|Vauxhall Wyvern]]&lt;br /&gt;[[w:Envoy (automobile)#Vauxhall Victor based models|Envoy F/FB/FC/FD]]&lt;br /&gt;Chevrolet Bedford AC/LQ&lt;br /&gt;Bedford WHG/WLG/WS/VYC/AS/WT/BYC/K/[[w:Bedford M series|MS/ML]]/OS/OL/[[w:Bedford OB|OB]]&lt;br /&gt;[[w:Bedford S type|Bedford S series]]&lt;br /&gt;[[w:Bedford SB|Bedford SB]]&lt;br /&gt;[[w:Bedford TA|Bedford TA]]&lt;br /&gt;[[w:Bedford HC|Bedford HC/JC/PC]]&lt;br /&gt;[[w:Bedford CA|Bedford CA/Envoy EA]]&lt;br /&gt;[[w:Bedford CF|Bedford CF/CF1/Opel Bedford Blitz]]&lt;br /&gt;[[w:Bedford HA|Bedford HA]]&lt;br /&gt;[[w:Vauxhall Slant-4 engine|Vauxhall Slant-4 engine]]&lt;br /&gt;Vauxhall OHV Inline-6&lt;br /&gt;[[w:Churchill tank|Churchill tank]] ||1905 (operations began)&lt;br&gt;&lt;br&gt;1925 (part of GM)||2002|| Vauxhall moved from London to Luton in 1905. GM bought Vauxhall in 1925. Chevrolet truck production was moved to Luton in 1930 from the Hendon plant and became known as Chevrolet Bedford. Chevrolet Bedford trucks were replaced by Vauxhall-developed Bedford trucks during 1931 though Chevrolet Bedford production continued through 1932. Bedford trucks and buses were built at Luton until production was moved to Dunstable in 1955. Subsequently, only Bedford vans and car-based light commercial vehicles were still made in Luton. Produced Churchill tanks during World War II. Production ended in 2002 with the [[w:Vauxhall Vectra|Vauxhall Vectra]]. Over 7.4 million vehicles had been produced. The Luton passenger car plant was next to the at the time still active van plant previously used by the IBC Vehicles joint venture. The plant has now been demolished and the site is now being redeveloped for housing.&lt;ref&gt;{{cite news|url=http://www.lutontoday.co.uk/news/politics/redevelopment-of-former-vauxhall-site-given-the-go-ahead-1-5795094|work=Luton Today|title=Redevelopment of former Vauxhall site given the go-ahead|date=8 Jan 2014|access-date=29 September 2014}}&lt;/ref&gt; It is being redeveloped into a new Luton suburb called [[w:Napier Park|Napier Park]]. The van plant was closed in 2025 by Stellantis. 

|- 

|&amp;nbsp;||GM de Venezuela&lt;br /&gt;Caracas||[[w:Antimano|Antimano]], [[w:Caracas|Caracas]]||[[w:Venezuela|Venezuela]]||[[w:Chevrolet Bel Air|Chevrolet Bel Air]]&lt;br /&gt;[[w:Chevrolet C/K|Chevrolet C/K]] &lt;br /&gt;[[w:Chevrolet Camaro|Chevrolet Camaro]]&lt;br /&gt; [[w:Chevrolet Caprice|Chevrolet Caprice]]&lt;br /&gt;[[w:Chevrolet Chevelle|Chevrolet Chevelle]]&lt;br /&gt;[[w:Chevrolet Corvair|Chevrolet Corvair]]&lt;br /&gt;[[w:Chevrolet Deluxe|Chevrolet Deluxe]]&lt;br /&gt;[[w:Chevrolet Impala|Chevrolet Impala]]&lt;br /&gt;[[w:Chevrolet Malibu|Chevrolet Malibu]]&lt;br /&gt; [[w:Chevrolet Nova|Chevrolet Nova]]&lt;br /&gt; [[w:Chevrolet Advance Design|Chevrolet Thriftmaster/Loadmaster]]&lt;br /&gt;[[w:Opel Kadett|Opel Kadett]]&lt;br /&gt;[[w:Opel Rekord|Opel Rekord]] ||1948||1983||Plant closed in 1983 &amp; GM moved to the newer Valencia plant that it bought from Chrysler in 1979.  

|- 

|&amp;nbsp;||GM Venezolana&lt;br /&gt;Mariara||[[w:Mariara|Mariara]], [[w:Carabobo|Carabobo]]||[[w:Venezuela|Venezuela]]||[[w:Chevrolet Silverado#Second-generation Silverado / third-generation Sierra (GMT900; 2007)|Chevrolet C3500]]&lt;br /&gt; [[w:Isuzu Forward|Chevrolet F-Series]]&lt;br /&gt;[[w:Isuzu Giga|Chevrolet E-Series]]&lt;br /&gt;[[w:Chevrolet Kodiak|Chevrolet Kodiak]]&lt;br /&gt;[[w:Isuzu Elf|Chevrolet N-Series]]&lt;br /&gt;||2008||2015||Plant closed in 2015 &amp; N-Series moved to Valencia plant.  

|- 

|&amp;nbsp;||GM Venezolana&lt;br /&gt;Valencia||[[w:Valencia, Carabobo|Valencia]], [[w:Carabobo|Carabobo]]||[[w:Venezuela|Venezuela]]||[[w:Chevrolet Astra|Chevrolet Astra]]&lt;br /&gt;[[w:Chevrolet Aveo (T200)|Chevrolet Aveo]]&lt;br /&gt; [[w:Chevrolet C/K|Chevrolet C/K]] &lt;br /&gt;[[w:Chevrolet Celebrity|Chevrolet Celebrity]]&lt;br /&gt;[[w:Buick Century#Fifth generation (1982–1996)|Chevrolet Century]]&lt;br /&gt;[[w:Chevrolet Chevette#Latin America|Chevrolet Chevette]]&lt;br /&gt;[[w:Chevrolet Corsa|Chevrolet Corsa]]&lt;br /&gt; [[w:Chevrolet Cruze#First generation (J300; 2008)|Chevrolet Cruze]]&lt;br /&gt;[[w:Chevrolet Tahoe#First generation (1992)|Chevrolet Grand Blazer]]&lt;br /&gt;[[w:Chevrolet Kodiak|Chevrolet Kodiak]]&lt;br /&gt; [[w:Chevrolet Malibu#Fourth generation (1978)|Chevrolet Malibu]]&lt;br /&gt;[[w:Opel Ascona#Chevrolet Monza|Chevrolet Monza]]&lt;br /&gt;[[w:Isuzu Elf|Chevrolet N-Series]]&lt;br /&gt;[[w:Daewoo Lacetti|Chevrolet Optra]]&lt;br /&gt;[[w:Chevrolet Orlando#First generation (J309; 2011)|Chevrolet Orlando]]&lt;br /&gt;[[w:Chevrolet S-10 Blazer|Chevrolet S-10 Blazer]]&lt;br /&gt;[[w:Chevrolet Silverado|Chevrolet Silverado]]&lt;br /&gt; [[w:Chevrolet Spark|Chevrolet Spark]]&lt;br /&gt;[[w:Chevrolet Tahoe|Chevrolet Tahoe]]&lt;br /&gt;[[w:Chevrolet TrailBlazer#First generation (KC; 2001)|Chevrolet TrailBlazer]] ||1979||2017||Originally built by Chrysler de Venezuela SA. GM bought the plant from Chrysler in 1979 and moved their entire operations there from the Caracas plant by 1983. &lt;br /&gt; 

There had already been production pauses because of part shortages between 2014 and 2016. On May 2, 2017 GM announced the total closure of the plant and deconsolidation of the Venezuelan unit from its accounts due to the illegal seizure of its factory by the Venezuelan government. The plant halted all of its operations of manufacturing vehicles and now only retains the GM brands representation.&lt;ref&gt;{{cite web|url=https://www.semana.com/internacional/articulo/general-motors-cierra-operaciones-en-venezuela/244829|title=General Motors concreta el cierre de sus operaciones en Venezuela|website=Semana.com|date=May 2, 2017}}&lt;/ref&gt;&lt;ref&gt;{{cite news|url=https://elpais.com/internacional/2017/04/20/actualidad/1492679446_631610.html|title=General Motors suspende operaciones en Venezuela tras el embargo de una planta|newspaper=El País|date=April 20, 2017|via=elpais.com}}&lt;/ref&gt;&lt;ref&gt;{{cite web|url=http://www.elcomercio.com/actualidad/generalmotors-cierre-operaciones-venezuela-negocios.html|title=General Motors inicia cierre de operaciones en Venezuela|website=El Comercio|date=May 2, 2017}}&lt;/ref&gt; 

|- 

|&amp;nbsp;||[[w:GM Vietnam|GM Vietnam]]||[[w:Hanoi, Vietnam|Hanoi]]||[[w:Vietnam|Vietnam]]||[[w:Chevrolet Aveo|Chevrolet Aveo]]&lt;br /&gt;[[w:Chevrolet Captiva#First generation (C100, C140; 2006)|Chevrolet Captiva]]&lt;br /&gt;[[w:Chevrolet Cruze#First generation (J300; 2008)|Chevrolet Cruze]]&lt;br /&gt;[[w:Chevrolet Lacetti|Chevrolet Lacetti]]&lt;br /&gt;[[w:Chevrolet Spark#Second generation (M200, M250; 2005)|Chevrolet Spark Lite]]&lt;br /&gt;[[w:Chevrolet Spark#Third generation (M300; 2009)|Chevrolet Spark]]&lt;br /&gt;[[w:Chevrolet Orlando#First generation (J309; 2011)|Chevrolet Orlando]]&lt;br /&gt;[[w:Chevrolet Vivant|Chevrolet Vivant]]&lt;br&gt;[[w:Daewoo Cielo|Daewoo Cielo]]&lt;br&gt;[[w:Daewoo Lacetti|Daewoo Lacetti]]&lt;br /&gt;[[w:Daewoo Lanos|Daewoo Lanos]]&lt;br&gt;[[w:Daewoo Leganza|Daewoo Leganza]]&lt;br&gt;[[w:Daewoo Magnus|Daewoo Magnus]]&lt;br&gt;[[w:Daewoo Matiz|Daewoo Matiz]]&lt;br&gt;[[w:Daewoo Nubira|Daewoo Nubira]]&lt;br&gt;[[w:Daewoo Damas|Daewoo Damas]]||1995||2018||Originally established as VIDAMCO (a joint venture with a state owned co.) in 1993 by Daewoo Motor Co. Daewoo bought out its Vietnamese partner in April 2000, making VIDAMCO 100% owned by Daewoo Motor Co. Bought by GM in 2002 as part of the creation of [[w:GM Daewoo|GM Daewoo Auto &amp; Technology Co.]] In July 2011, the name of the company was changed from VIDAMCO to GM Vietnam. Sold to [[w:VinFast|VinFast]] in 2018. [[w:VinFast Fadil|VinFast Fadil]] produced under license from GM; is a rebadged [[w:Chevrolet Spark#Fourth generation (M400; 2015)|Chevrolet Spark (M400)]]/[[w:Opel Karl|Opel Karl]].  

|- 

|&amp;nbsp;||[[w:Warren Transmission|Warren Transmission]]||[[w:Warren, Michigan|Warren, Michigan]]||United States||[[w:GM-Ford 6-speed automatic transmission|6T70, 6T75, 6T80]] ||1958||2020||Located at 23500 Mound Road. Past transmissions: [[w:GM 4T60-E transmission|4T65-E]], [[w:List of GM transmissions#Hybrid and PHEV|5ET50 EVT]] 

Plant originally built in 1941 as a US Navy Ordnance facility operated by the Hudson Motor Car Co. building 20mm Oerlikon anti-aircraft guns. In 1943, the Navy moved the contract from Hudson to Westinghouse, which now operated the Warren plant for the Navy. Ford bought the plant in 1946 and used it to produce axles and ball joints. GM bought the plant in 1958.&lt;ref&gt;{{Cite web|url=https://gmauthority.com/blog/2022/01/old-gm-warren-transmission-plant-set-to-be-demolished/|title = Old GM Warren Transmission Plant Set To Be Demolished|author=Sam McEachern|publisher=GMAuthority.com|date=January 25, 2022}}&lt;/ref&gt; The plant became a Chevrolet facility making auto parts. It also made artillery shells in the 1960's and 1970's. The factory was transferred to the Hydramatic Division in 1980, later becoming part of GM Powertrain. [https://nadc1.com/?portfolio=gm-paint-shop-strip-out] Ended production on August 1, 2019. Reopened for production of face masks during the COVID-19 pandemic beginning in March 2020&lt;ref&gt;{{Cite web|url=https://www.freep.com/story/money/cars/general-motors/2020/06/08/gm-warren-transmission-plant-coronavirus/3135789001/|title = GM revived Warren plant for face mask production. What happens when demand slows?|author=Jamie LaReau|publisher=Detroit Free Press|date=June 8, 2020}}&lt;/ref&gt;. First face mask produced March 27, 2020. Sold to a developer in 2021.

|- 

|&amp;nbsp;||[[w:Welch Motor Car Company|Welch]]||[[w:Pontiac, Michigan|Pontiac]], [[w:Michigan|Michigan]]||United States||Welch automobiles||1909||1911||Welch Motor Car Company became affiliated with GM in 1909 and GM officially took it over in 1910. Welch ended production in 1911. Welch was noted for having engines with a single overhead cam and hemispherical combustion chambers, unusual technology for its time.

|-

|&amp;nbsp;||[[w:Welch Motor Car Company|Welch-Detroit]]||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||Welch-Detroit automobiles||1910||1911||The Welch Company of Detroit was a separate company from the Welch Motor Car Company of Pontiac, Michigan and was set up in June 1909 to build a smaller, cheaper car than the Welch made in Pontiac, Michigan. Both Welch companies became affiliated with GM in 1909 and GM officially took over both companies in 1910. Both Welch and Welch-Detroit ended production in 1911. Equipment from the factory was moved to the also GM-owned, former Rainier Motor Car Company factory in Saginaw to make the 1912 Marquette, which was said to be a combination of the previous Rainier and Welch-Detroit brands.

|-

|W||[[w:Willow Run Assembly|Willow Run Assembly]]||[[w:Ypsilanti Township, Michigan|Ypsilanti Twp, Michigan]]||United States||[[w:Chevrolet Caprice#Fourth generation (1991–1996)|Chevrolet Caprice]] sedan &amp; wagon (1991-1993) &lt;br /&gt;[[w:Oldsmobile Custom Cruiser#Third generation (1991–1992)|Oldsmobile Custom Cruiser]] wagon (1991-1992)&lt;br /&gt;[[w:Buick Roadmaster#1991–1996|Buick Roadmaster Estate wagon]] (1991-1993)||1956||1993||Located at 2625 Tyler Road, to the south of the former Willow Run Transmission plant. Initially opened in 1956 to exclusively build Chevrolet trucks in a 500,000 sq. ft. building that had been used as a warehouse by GM and was previously used by Kaiser-Frazer's engineering dept. [https://aadl.org/aa_news_19561208-chevrolet_willow_run_truck_plant_gains_momentum] In 1958-59, plant was expanded into a 2-part Chevrolet &amp; Fisher Body passenger car assembly plant to make the Chevrolet Corvair. First completed 1960 Corvair rolls off the line on July 7, 1959 [https://www.facebook.com/photo/?fbid=792700342891740&amp;set=a.453129043515540]. Added the Chevy II (Nova) for 1962. Was part of the [[w:Chevrolet Assembly Division|Chevrolet Assembly Division]]. Chevrolet Assembly Division plants, along with the onsite Fisher Body plants, were gradually transferred to the GM Assembly Division which replaced the BOP Assembly Division in 1965. Willow Run Assembly joined the GM Assembly Division in 1971. Idled in Nov. 1978. Converted in 1978-79 to build the fwd X-body compacts for 1980. Began building fwd X-cars on January 17, 1979. In 1984, joined the new BOC group in preparation for its conversion to build the new fwd H-body full-size cars for 1986. Final H-car built on May 19, 1989 and in September, moved to the CPC group. Converted to build the body-on-frame, rwd B-body for 1991. Chevy Caprice sedan production began in January 1990 followed by station wagons in July. Closed July 1993. B-body production consolidated in Arlington, TX. Assembly plant was 2.5 million sq. ft. when it closed. The Willow Run Assembly Plant is now the Willow Run Business Center, a multi-tenant warehouse and distribution facility, part of which is leased by GM to distribute automotive service parts, which is known as Ypsilanti #87 Processing Center, part of GM Customer Care and Aftersales.  The nearby Willow Run Company Vehicle Operations site at 2901 Tyler Road was sold to International Turbine Industries in April 2013.&lt;ref name=WR-Assembly-sold&gt;{{cite news|author=Katrease Stafford|title=GM Willow Run plant redevelopment: Aircraft maintenance firm buys 1 building|url=https://www.annarbor.com/news/ypsilanti/gm-willow-run-plant-redevelopment-aircraft-maintenance-firm-purchases-facility-25-new-jobs-expected/|access-date=24 April 2013|newspaper=AnnArbor.com|date=April 2, 2013}}&lt;/ref&gt; 
Past models: [[w:Chevrolet Task Force|Chevrolet Task Force]] (1957-1958), [[w:Chevrolet Suburban#Fourth generation (1955)|Chevrolet Suburban]] (1958), [[w:Chevrolet Corvair|Chevrolet Corvair]] (1960-1969), [[w:Chevrolet Nova|Chevrolet Chevy II/Nova]] (1962-79), [[w:Acadian (automobile)|Acadian]] (Canada only: 1968-71), [[w:Pontiac Ventura#1971–1977 X-body compact|Pontiac &lt;br&gt; Ventura]] (1971-1977), [[w:Pontiac GTO#Fourth generation|Pontiac GTO]] (1974), [[w:Pontiac Phoenix#First generation (1977–1979)|Pontiac Phoenix (rwd &lt;br&gt; X-body)]] (1977-1979), [[w:Oldsmobile Omega|Oldsmobile Omega (rwd X-body)]] (1973-1979), [[w:Buick Skylark#Fourth generation (1975–1979)|Buick Skylark (rwd &lt;br&gt; X-body)]] (1977-1978), [[w:Chevrolet Citation|Chevrolet Citation]] (1980-1981, 1984-1985), [[w:Oldsmobile Omega#Third generation (1980–1984)|Oldsmobile Omega (fwd X-body)]] (1980-1984), [[w:Buick Skylark#Fifth generation (1980–1985)|Buick Skylark (fwd &lt;br&gt; X-body)]] (1980-1985), [[w:Oldsmobile 88#Ninth generation (1986–1991)|Oldsmobile 88]] (1986-89), [[w:Pontiac Bonneville#Eighth generation (1987–1991)|Pontiac Bonneville]] (1987-1989).

|-

|&amp;nbsp;||[[w:Willow Run Transmission|Willow Run Transmission]]||[[w:Ypsilanti, Michigan|Ypsilanti, Michigan]]||United States|| [[w:Hydramatic|Hydramatic]] automatic transmissions &lt;br /&gt; [[w:GM 4L80-E transmission|4L80-E transmission]]&lt;br /&gt;[[w:GM 4L80-E transmission|4L85-E transmission]]&lt;br /&gt;[[w:GM 4T60-E transmission|4T60-E transmission]]&lt;br /&gt;[[w:GM 4T60-E transmission|4T65-E transmission]]&lt;br /&gt;[[w:GM 4T80-E transmission|4T80-E transmission]]&lt;br /&gt;[[w:GM 6L50 transmission|6L50-E transmission]]&lt;br /&gt;[[w:GM 6L80 transmission|6L80-E transmission]]&lt;br /&gt;[[w:GM 6L90 transmission|6L90-E transmission]]&lt;br /&gt;||1953||2010||Began as the Ford [[w:B-24 Liberator|B-24 Liberator]] bomber plant in World War II which opened in 1941, grew from 3.5 million square feet to nearly 5 million square feet under GM. Ford built the factory and sold it to the US government, which leased it back to Ford for the duration of WWII. Ford Motor had first option on the plant after war production ended, an option it ultimately chose not to exercise. The factory was instead leased and then sold to [[w:Kaiser-Frazer|Kaiser-Frazer]] and was their main production site from 1946-1953, when they moved production to Toledo, OH following Kaiser-Frazer's acquisition of Toledo-based [[w:Willys-Overland|Willys-Overland]]. In addition to automobiles, [[w:Kaiser-Frazer|Kaiser-Frazer]] also built [[w:C-119 Flying Boxcar|C-119 Flying Boxcar]] cargo planes at Willow Run under license from [[w:Fairchild Aircraft|Fairchild Aircraft]], producing an estimated 88 C-119s between 1951 and 1953. In 1953, GM first leased then bought the plant to replace the Detroit Transmission Division factory in Livonia, Michigan that had burned down earlier in 1953. Whatever equipment could be salvaged was brought from the destroyed Detroit Transmission Division plant in Livonia to Willow Run in 1953. Also supplied Hydramatics to Lincoln, Nash, Hudson, Rambler, Kaiser, and Willys. It was also initially supplied to Rolls-Royce before Rolls-Royce set up their own Hydramatic production line in the UK building Hydramatics under license from GM. Rolls-Royce also supplied Armstrong-Siddeley and [[w: British Motor Corporation|BMC]], which in turn supplied other British automakers like Jensen that used BMC’s biggest engines. The Detroit Transmission Division became the Hydramatic Division in October 1963. The Hydramatic Division merged with the GM Engine Division to form GM Powertrain in 1991-1992. Over the years, GM expanded the plant to almost 5 million sq. ft. In addition to automatic transmissions, GM also produced the M16A1 rifle and the M39A1 20mm autocannon for the US military during the Vietnam War at Willow Run Transmission. GM Powertrain also had an on-site engineering center. The plant closed in December 2010. A small portion of the plant was saved by the [[w:Yankee Air Museum|Yankee Air Museum]] to be turned into the National Museum of Aviation and Technology at Historic Willow Run but more than 95% of the plant was demolished from 2013-2014. The rest of the site has been redeveloped into the [[w:American Center for Mobility|American Center for Mobility]], an autonomous- and connected-driving testing center which opened in December 2017.  

|-

|Y (1964 [[w:Chevrolet|Chevrolet]] and 1965-2010) &lt;br /&gt;&lt;br /&gt; W &lt;br /&gt; (Pre-1965 [[w:Oldsmobile|Oldsmobile]] &amp; [[w:Pontiac (automobile)|Pontiac]])&lt;br /&gt;&lt;br /&gt; 5 (Pre-1965 [[w:Buick|Buick]]) || [[w:Wilmington Assembly|Wilmington Assembly]] || [[w:Wilmington, Delaware|Wilmington, Delaware]]||United States||[[w:Pontiac Solstice|Pontiac Solstice]] (2006-2010)&lt;br /&gt;[[w:Saturn Sky|Saturn Sky]] (2007-2010) &lt;br /&gt;[[w:Opel GT#GT (roadster) (2007–2010)|Opel GT]] (Europe: 2007-2010) &lt;br /&gt;[[w:Daewoo G2X#Daewoo G2X|Daewoo G2X]] (S. Korea: 2007-2009) ||1947||2009||Located at 801 Boxwood Road. Was originally part of the [[w:Buick-Oldsmobile-Pontiac Assembly Division|Buick-Oldsmobile-Pontiac Assembly Division]]. Wilmington began making Chevrolet passenger cars for 1964. BOP Assembly Division became GM Assembly Division in 1965. Converted to make the Chevette small car for 1976. Switched back to making B-body full-size cars for 1985. Converted to make the fwd Chevy Corsica &amp; Beretta for 1987. Then built Corsica's replacement, Malibu, for 1997. Converted to build Saturn's 2nd model range, the Opel Vectra-based, plastic body paneled Saturn L-Series for 2000. Converted to build the rwd, Kappa platform small sports cars for 2006 beginning with the Pontiac Solstice. Final car produced was a Solstice roadster on July 28, 2009. The plant was sold to [[w:Fisker Automotive|Fisker Automotive]] in 2010, which had planned to build its [[w:Fisker Atlantic|2nd model line]] there. However, Fisker Automotive went bankrupt in Nov. 2013 before ever building any cars in Wilmington. Fisker Automotive's assets, including the Wilmington plant, were purchased out of bankruptcy by Wanxiang Group in February 2014. Wanxiang did not use the plant and sold it in 2017. Plant was demolished in 2019. A large part of the site is now an Amazon fulfillment center.&lt;br /&gt;Past models: [[w:Chevrolet Corsica|Chevrolet Corsica]] (1987-1996), [[w:Chevrolet Beretta|Chevrolet Beretta]] (1987-1996), [[w:Pontiac Tempest#Fourth generation (1987–1991)|Pontiac Tempest (Canada only)]] (1988-91), [[w:Chevrolet Malibu#Fifth generation (1997)|Chevrolet Malibu]] (1997-1999), [[w:Saturn L-Series|Saturn L-Series]] (2000-2005), [[w:Chevrolet Chevette|Chevrolet Chevette]] (1976-1984), [[w:Pontiac 1000|Pontiac 1000]] (1981-1984), [[w:Pontiac Acadian|Pontiac Acadian]] (Canada only: 1976-1984), [[w:Buick Centurion|Buick Centurion]] (1971-1973), [[w:Buick Electra|Buick Electra]] (1959-1962, 1971-1974), [[w:Buick Estate#1971-1976|Buick Estate]] (1972-1973, 1975), [[w:Buick GS|Buick GS]] (1968-1969), [[w:Buick Invicta|Buick Invicta]] (1959-1962), [[w:Buick LeSabre|Buick LeSabre]] (1959-1975), [[w:Buick Limited#1958 Limited|Buick Limited]] (1958), [[w:Buick Roadmaster|Buick Roadmaster]] (1948-1950, 1955-1957), [[w:Buick Skylark#Third generation (1968–1972)|Buick Skylark]] (1968-1969), [[w:Buick Special|Buick Special]] (1950, 1953-1958), [[w:Buick Super|Buick Super]] (1954-1958), [[w:Buick Wildcat|Buick Wildcat]] (1963-1970), [[w:Chevrolet Bel Air|Chevrolet Bel Air]] (1964), [[w:Chevrolet Biscayne|Chevrolet Biscayne]] (1964-1968), [[w:Chevrolet Caprice|Chevrolet Caprice]] (1966-1975, 1985-1986), [[w:Chevrolet Impala|Chevrolet Impala]] (1964-1975, 1985), [[w:Oldsmobile 88|Oldsmobile 88]] (1949-1963, 1985), [[w:Oldsmobile 98|Oldsmobile 98]] (1948-1963), [[w:Oldsmobile Starfire#First generation (1961–1966)|Oldsmobile Starfire]] (1961-1963), [[w:Pontiac Bonneville|Pontiac Bonneville]] (1958-1963), [[w:Pontiac Catalina|Pontiac Catalina]] (1959-1960, 1962-1963), [[w:Pontiac Chieftain|Pontiac Chieftain]] (1950-1951, 1954-1957), [[w:Pontiac Grand Prix#First generation (1962–1964)|Pontiac Grand Prix]] (1962-1963), [[w:Pontiac Star Chief|Pontiac Star Chief]] (1955-1958, 1960), [[w:Pontiac Ventura#1960–1970|Pontiac Ventura]] (1960-1961) 

|- 

|&amp;nbsp;||[[w:Windsor Transmission|Windsor Transmission]]||[[w:Windsor, Ontario|Windsor, Ontario]]||[[w:Canada|Canada]]||[[w:GM 4T40 transmission|4T40E/4T45E transmission]]&lt;br /&gt;Transmission components||1920||2010||Plant was originally in [[w:Walkerville, Ontario|Walkerville]] until Walkerville was annexed by Windsor in 1935. Was located at 1550 Kildare Road. Walker Road is at the back of the property. Previous: 1920 - 1928 axles and parts, 1928 - 1963 engines (including the [[w:Chevrolet Stovebolt engine|Chevrolet Stovebolt OHV inline-6 engine]] and Buick engines from 1935-1942). The Windsor plant was taken over by McKinnon Industries Ltd., a GM subsidiary based in St. Catharines, Ontario, Canada in 1963. As a result, engine production in Windsor was moved to St. Catharines and transmission production in St. Catharines was moved to Windsor. At this point, the Windsor plant was renamed the Windsor Transmission Plant. In 1969, McKinnon Industries Ltd. was integrated into GM Canada rather than being a separate subsidiary. Windsor Transmission was closed on July 28, 2010. The 4-spd. automatics made in Windsor were discontinued and replaced by 6-spd. automatics made in St. Catharines. Sold in 2014 and completely demolished by 2017. Site now occupied by MotiPark Ltd. 

|- 

|&amp;nbsp;||Windsor Trim||[[w:Windsor, Ontario|Windsor, Ontario]]||[[w:Canada|Canada]]||Seat assemblies and door trim panels||1965||1996|| Located at 1600 Lauzon Rd. Sold to Peregrine, Inc. in 1996 and then sold to [[w:Lear Corp.|Lear Corp.]] in 1999. Closed by Lear in 2005. Demolished in 2009. Part of the property is now the [[w:WFCU Centre|WFCU Centre]] and part will be residential homes. 

|- 

|&amp;nbsp;||[[w:Wixom Performance Build Center|Wixom Performance Build Center]]||[[w:Wixom, Michigan|Wixom, Michigan]]||United States||[[w:GM LS engine|6.2L LS3 V8]] [[w:Chevrolet Corvette (C6)#Grand Sport|(C6 Corvette Grand Sport coupe w/manual transmission only)]]&lt;br /&gt;[[w:GM LS engine|7.0L LS7 V8]]&lt;br /&gt;[[w:GM LS engine|6.2L supercharged LS9 V8]]&lt;br /&gt;[[w:Northstar engine series#LC3|4.4L supercharged LC3 Northstar V8]] ||2004||2013&lt;ref&gt;{{Cite web|url=https://www.torquenews.com/106/gm-closing-wixom-performance-engine-facility-build-your-own-engine-program-ends|title=GM Closing Wixom Performance Engine Facility, Build-Your-Own-Engine Program Ends|author=Patrick Rall|date=September 20, 2013|publisher=Torquenews.com}}&lt;/ref&gt;||Located at 30240 Oak Creek Dr.&lt;br&gt; Performance Build Center relocated to &lt;br&gt; Bowling Green Assembly in 2014. 

|- 

|&amp;nbsp;||[[w:Detroit Assembly#LaSalle Factory/DeSoto Factory|Wyoming Assembly (LaSalle Wyoming Ave. plant)]]||[[w:Detroit|Detroit]], [[w:Michigan|Michigan]]||United States||[[w:LaSalle (automobile)|LaSalle]] 1927-1933||1926||1934||Located at 6000 Wyoming Avenue. Originally built to produce Liberty aircraft engines in World War I, opening in 1917. In 1919, was taken over by Saxon Motor Co., owned by Hugh Chalmers of Chalmers Motor Co. GM bought the plant in 1926 and built the LaSalle there from 1927. GM sold Wyoming Assembly to Chrysler in 1934, which then used it to build its DeSoto brand. After the DeSoto brand was discontinued in late 1960, became Wyoming Export plant which was used to prepare vehicles for export. Plant closed in 1980. Plant was demolished in 1992.  

|-

|&amp;nbsp;||[[w:GMC (marque)#History|Yellow Truck &amp; Coach Manufacturing Company]]||[[w:Chicago|Chicago]], [[w:Illinois|Illinois]]||United States||Yellow Cab taxis&lt;br&gt;Yellow Coach buses&lt;br&gt;Yellocab trucks (T-1, T-2, and T-3)||1925||1928||Located on West Dickens Ave. In 1925, General Motors Truck Corp., the parent of the GMC brand, merged with Yellow Cab Manufacturing Company (including its Yellow Coach Mfg. Co. bus-making subsidiary) to form Yellow Truck &amp; Coach Manufacturing Company, in which GM owned a majority stake of 57%. Yellocab trucks were discontinued during 1927 and were replaced with new light-duty GMC trucks (T-10 &amp; T-20). During 1928, bus and taxi production was consolidated at the GMC Pontiac Central plant in Pontiac, Michigan. The Chicago plant was closed and sold.
 
|-

|&amp;nbsp;||Yellow Sleeve-Valve Engine Works||[[w:East Moline|East Moline]], [[w:Illinois|Illinois]]||United States||Yellow-Knight engines||1925||1929||Production began in 1923. In 1925, General Motors Truck Corp., the parent of the GMC brand, merged with Yellow Cab Manufacturing Company (including its Yellow Coach Mfg. Co. bus-making subsidiary) to form Yellow Truck &amp; Coach Manufacturing Company, in which GM owned a majority stake of 57%. The Northway Motor Division of Detroit was transferred to General Motors Truck Corp. as part of that merger but was liquidated in 1926. During 1929 and 1930, Yellow Sleeve Valve Engine production equipment was transferred from East Moline, Illinois to Pontiac West Plant 1 in Pontiac, Michigan. The East Moline plant was closed at the end of 1929 and was sold.

|-

|&amp;nbsp;||[[w:Yulon GM|Yulon GM]]||[[w:Miaoli|Miaoli]]||[[w:Taiwan|Taiwan]]||[[w:Buick Excelle#Taiwan|Buick Excelle]]&lt;br /&gt;[[w:Buick LaCrosse#China|Buick LaCrosse]]  ||2006||2012||A joint venture owned 49% by GM &amp; 51% by [[w:Yulon|Yulon Motor Co]]. Yulon bought GM's stake in the venture in Dec. 2008. Production continued after the sale through licensing but cooperation between GM &amp; Yulon ended in 2012.  

|- 

|&amp;nbsp;||General Motors Zaire||[[w:Kinshasa|Kinshasa]]||[[w:Zaire|Zaire]] (now [[w:Democratic Republic of the Congo|D.R. Congo]])||[[w:Chevrolet|Chevrolet]] trucks&lt;br /&gt;[[w:Opel Kadett|Opel Kadett]]&lt;br /&gt;[[w:Opel Rekord|Opel Rekord]]&lt;br /&gt;[[w:Opel Commodore|Opel Commodore]]&lt;br /&gt;[[w:Opel Ascona|Opel Ascona]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford Trucks]]||1975||1987||GM sold the plant in 1987 to local businessmen. Plant was looted bare in 1991.  

|}

== Former partner factories == 

 
{| class=&quot;wikitable sortable&quot; style=&quot;font-size:90%&quot; 

!VIN !! Name !! City/State !! Country !! class=&quot;unsortable&quot; | Products !! Opened !! Idled !! class=&quot;unsortable&quot; | Comments 

|- 

|H||[[w:AM General#Hummer brand|AM General]] Commercial plant||[[w:Mishawaka, Indiana|Mishawaka, Indiana]]||United States||[[w:Hummer H2|Hummer H2]] (2003-2009)||2002||2009||Located at 12900 McKinley Highway. Built under contract for GM by AM General. Plant later built the [[w:Mercedes-Benz R-Class|Mercedes-Benz R-Class]] under contract for Mercedes for export to China from 2015-2017 as well as the [[w:VPG MV-1|VPG MV-1]] under contract for VPG (later Mobility Ventures MV-1; Mobility Ventures being an AM General subsidiary that took over VPG's assets after VPG went bankrupt). MV-1 was made from 2011-2016.

|- 

|E||[[w:AM General#Hummer brand|AM General]] Military plant||[[w:Mishawaka, Indiana|Mishawaka, Indiana]]||United States||[[w:Hummer H1|Hummer H1]] (2000-2006)||1992 (civilian production)||2006 (civilian production)||Located at 13200 McKinley Highway. This plant built the military [[w:Humvee|Humvee]] from fall 1984 and civilian Hummers from 1992. In Dec. 1999, GM bought the rights to the Hummer brand from AM General. AM General still handled manufacturing but GM handled marketing and distribution. At this point, the AM General Hummer was renamed Hummer H1. H1 built under contract for GM by AM General. Humvee production for military use continued after 2006.

|- 

|&amp;nbsp;||Asoke Engineering (Asoke Motors)||Bangkok?||[[w:Thailand|Thailand]]||[[w:Bedford HA#The BTV|Plai Noi]]&lt;br /&gt;[[w:Opel Rekord|Opel Rekord]]||Mid-1970s||Early-1980s||A version of GM's [[w:Bedford HA#The BTV|BTV]] called the Plai Noi was assembled in Thailand in 1974.

|- 

|&amp;nbsp;||Associated Industries Ltd.||[[w:Georgetown, Guyana|Georgetown]]||[[w:Guyana|Guyana]]||[[w:Bedford HA#The BTV|Tapir]]||Mid-1970's||Late-1970's||A version of GM's [[w:Bedford HA#The BTV|BTV]] called the Tapir was assembled in Guyana. 

|- 

|&amp;nbsp;||Associated Motor Industries Ltd.||[[w:Jurong|Jurong]] (Jurong Industrial Estate)||[[w:Singapore|Singapore]]||[[w:Chevrolet Impala|Chevrolet Impala]]&lt;br /&gt;[[w:Statesman (automobile)#HQ|Chevrolet 350]]&lt;br /&gt;[[w:Vauxhall Motors|Vauxhall]] including: &lt;br /&gt;[[w:Vauxhall Victor|Victor]]&lt;br /&gt;[[w:Vauxhall Viva|Viva]]&lt;br /&gt;[[w:Vauxhall VX4/90|VX4/90]]||1968||1975||Jointly owned by Wearne Brothers Limited &amp; Motor Investments Bhd. Associated Motor Industries Ltd. assembled vehicles under license from GM beginning in 1968 as well as brands from other automakers (Austin, Morris, &amp; Renault).  

|- 

|&amp;nbsp;||Associated Motor Industries Malaysia Sdn. Bhd.||[[w:Batu Tiga|Batu Tiga]], [[w:Selangor|Selangor]]||[[w:Malaysia|Malaysia]]||[[w:Holden|Holden]]&lt;br /&gt;||1968||1971 (?)||Associated Motor Industries Malaysia assembled Holden vehicles under license from GM beginning in 1968 as well as brands from other automakers.  

|- 

|C||[[w:Automobilwerk Eisenach|Automobilwerk Eisenach]] (AWE)||[[w:Eisenach|Eisenach]]||[[w:Germany|Germany]]||[[w:Opel Vectra#Vectra A (1988–1995)|Opel Vectra]] A&lt;br /&gt;||1990||1991||  The old [[w:Wartburg (marque)|Wartburg]] plant built vehicles for Opel for a short time before closing permanently.  

|- 

|&amp;nbsp;||[[w:Avtotor|Avtotor]]||[[w:Kaliningrad|Kaliningrad]]||[[w:Russia|Russia]]||[[w:Chevrolet Aveo (T200)|Chevrolet Aveo]], [[w:Chevrolet Captiva#First generation (C100, C140; 2006)|Chevrolet Captiva]], [[w:Chevrolet Epica|Chevrolet Epica]], [[w:Chevrolet Lacetti|Chevrolet Lacetti]], [[w:Chevrolet Malibu#Eighth generation (2013)|Chevrolet Malibu]], [[w:Chevrolet Orlando#First generation (J309; 2010)|Chevrolet Orlando]], [[w:Chevrolet Rezzo|Chevrolet Rezzo]], [[w:Chevrolet Tahoe#Second generation (2000) |Chevrolet Tahoe (GMT800)]], [[w:Chevrolet Tahoe#Third generation (2007)|Chevrolet Tahoe (GMT900)]], [[w:Chevrolet Trailblazer (SUV)#First generation (KC; 2001)|Chevrolet Trailblazer]], [[w:Cadillac BLS|Cadillac BLS]], [[w:Cadillac CTS|Cadillac CTS]], [[w:Cadillac Escalade#Second generation (2001)|Cadillac Escalade (GMT800)]], [[w:Cadillac Escalade#Third generation (2007)|Cadillac Escalade (GMT900)]], [[w:Cadillac SRX|Cadillac SRX]], [[w:Cadillac STS|Cadillac STS]], [[w:Hummer H2|Hummer H2]], [[w:Hummer H3|Hummer H3]], [[w:Opel Antara|Opel Antara]], [[w:Opel Astra|Opel Astra]], [[w:Opel Insignia|Opel Insignia]], [[w:Opel Mokka#First generation (J13; 2012)|Opel Mokka]], [[w:Opel Meriva|Opel Meriva]], [[w:Opel Zafira|Opel Zafira]]||2004||2015||Built under contract by [[w:Avtotor|Avtotor]] for GM. GM ended the contract in 2015.  

|- 

|&amp;nbsp;||Azia Avto||[[w:Ust-Kamenogorsk|Ust-Kamenogorsk]]||[[w:Kazakhstan|Kazakhstan]]||[[w:Chevrolet Aveo (T200)|Chevrolet Aveo]], [[w:Chevrolet Captiva#First generation (C100, C140; 2006)|Chevrolet Captiva]], [[w:Chevrolet Cruze|Chevrolet Cruze]], [[w:Chevrolet Epica|Chevrolet Epica]], [[w:Chevrolet Lacetti|Chevrolet Lacetti]], [[w:Chevrolet Malibu#Eighth generation (2013)|Chevrolet Malibu]], [[w:Chevrolet Orlando#First generation (J309; 2010)|Chevrolet Orlando]], [[w:Chevrolet Trax|Chevrolet Tracker]]||2007||2018||Built under contract by Azia Avto for GM.  

|- 

|&amp;nbsp;||[[w:Bangchan General Assembly|Bangchan General Assembly]] Co., Ltd.||[[w:Khan Na Yao district|Khan Na Yao district]], [[w:Bangkok|Bangkok]]||[[w:Thailand|Thailand]]||[[w:Opel Kadett|Opel Kadett]] &lt;br /&gt;[[w:Opel Rekord|Opel Rekord]] &lt;br /&gt;[[w:Holden Kingswood|Holden Monaro LS]]&lt;br /&gt;[[w:Statesman (automobile)|Chevrolet De Ville]]||1970||1987 (?)||[[w:Isuzu|Isuzu]] invested in Bangchan in 1979 but then sold its stake to [[w:Honda|Honda]] in 1987. Phra Nakorn Automobile Group became sole owner of Bangchan in 2005.  

|- 

|B||[[w:Gruppo Bertone|Gruppo Bertone]]||[[w:Grugliasco|Grugliasco]]||[[w:Italy|Italy]]||[[w:Opel Kadett#Kadett E (1984–1995)|Opel Kadett E convertible]]&lt;br /&gt;[[w:Vauxhall Astra#Second generation (1984–1993)|Vauxhall Astra Mark 2 convertible]]&lt;br /&gt;[[w:Opel Astra#F|Opel/Vauxhall Astra F convertible]]&lt;br /&gt;[[w:Opel Astra#G|Opel/Vauxhall Astra G coupe &amp; convertible]]&lt;br /&gt;[[w:Holden Astra#Fourth generation (TS; 1998)|Holden Astra convertible (TS)]] ||1987||2006||Built under contract by [[w:Gruppo Bertone|Gruppo Bertone]] for Opel/Vauxhall.  

|- 

|&amp;nbsp;||Central African Transport Company (CATCO)||?||[[w:Malawi|Malawi]]||[[w:Bedford HA#The BTV|Zonse]]||Mid-1970's||?||A version of GM's [[w:Bedford HA#The BTV|BTV]] called the Zonse was assembled in Malawi. 

|-

|&amp;nbsp;||Centroamericana de Ensamblaje y Fabricación||(?)||[[w:Honduras|Honduras]]||[[w:El Compadre (car)|Compadre]]||1970s||(?)||A version of GM's [[w:Bedford HA#The BTV|BTV]] called the Compadre was assembled in Honduras.

|-

|&amp;nbsp;||Champion Motors||[[w:Shah Alam|Shah Alam]], [[w:Selangor|Selangor]]||[[w:Malaysia|Malaysia]]||[[w:Chevrolet Impala|Chevrolet Impala]]&lt;br /&gt;[[w:Vauxhall Victor|Vauxhall Victor]]&lt;br /&gt;[[w:Vauxhall Viva|Vauxhall Viva]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford trucks]] including [[w:Bedford TJ|Bedford TJ]]||1968||1982 (?)||Champion Motors assembled vehicles under license from GM beginning in 1968. Champion Motors was renamed Assembly Services Sdn. Bhd. (ASSB) in 1975. The last products still being built for GM were Bedford trucks. A joint venture of Toyota &amp; [[w:UMW Holdings|UMW Holdings Bhd.]] called Sejati Motor took over ASSB in 1982. Sejati Motor was renamed UMW Toyota Motor in 1987. ASSB is a subsidiary of UMW Toyota Motor.

|- 

|&amp;nbsp;||Chinese Automobile Co., Ltd.||[[w:Xinzhuang District|Xinzhuang District]], [[w:New Taipei City|New Taipei City]]||[[w:Taiwan|Taiwan]]||[[w:Opel Astra|Opel Astra]] F &amp; G&lt;br /&gt;[[w:Opel Vectra#Vectra B (1995–2002)|Opel Vectra]] B ||1993||2000||GM ended the assembly contract in 2001.  

|- 

|&amp;nbsp;||Fabrica Superior de Centro America S.A.||?||[[w:El Salvador|El Salvador]]||[[w:Bedford HA#The BTV|Cherito]]||1973||1975||A version of GM's [[w:Bedford HA#The BTV|BTV]] called the Cherito was assembled in El Salvador. It was distributed by Auto Palace.

|-

|&amp;nbsp;||Fernandes Autohandel||?||[[w:Suriname|Suriname]]||[[w:Bedford HA#The BTV|Moetete]]||1973||1975||A version of GM's [[w:Bedford HA#The BTV|BTV]] called the Moetete was assembled in Suriname. 

|- 

|&amp;nbsp;||[[w:GAZ|GAZ]]||[[w:Nizhny Novgorod|Nizhny Novgorod]]||[[w:Russia|Russia]]||[[w:Chevrolet Aveo#Second generation (T300; 2012)|Chevrolet Aveo]]||2013||2015||Built under contract by [[w:GAZ|GAZ]] for GM. GM ended the contract in 2015.  

|- 

|&amp;nbsp;||Genoto (General Otomotiv Sanayi ve Ticaret AS)||[[w:Kozyatağı|Kozyatağı]], [[w:Istanbul|Istanbul]]||[[w:Turkey|Turkey]]||[[w:Bedford Vehicles|Bedford trucks]] including [[w:Bedford TK|Bedford TK]] (KG EJR &amp; KBC 10 &amp; 570)||1965||1986||Built Bedford trucks under license from GM, sometimes rebadged as Genoto. 

|- 

|E||[[w:Heuliez|Heuliez]]||[[w:Cerizay|Cerizay]]||[[w:France|France]]||[[w:Opel Tigra#Tigra TwinTop B (2004–2009)|Opel/Vauxhall Tigra TwinTop B]]&lt;br /&gt;[[w:Opel Tigra#Tigra TwinTop B (2004–2009)|Holden Tigra (XC)]]||2004||2009||Built under contract by [[w:Heuliez|Heuliez]] for Opel/Vauxhall.  

|- 

|&amp;nbsp;||[[w:Hindustan Motors|Hindustan Motors]]||[[w:Uttarpara|Uttarpara]], [[w:West Bengal|West Bengal]]||[[w:India|India]]||[[w:Vauxhall Motors|Vauxhall]] models under Hindustan name including [[w:Hindustan Contessa|Hindustan Contessa]] (based on [[w:Vauxhall Victor|Vauxhall Victor]])&lt;br /&gt;[[w:Bedford Vehicles|Bedford]] models including [[w:Bedford TJ|Bedford TJ]]&lt;br /&gt;[[w:Allison Transmission|Allison Transmission]]&lt;br /&gt;[[w:Terex|Terex]]||1957 (?)||2004||Built under license by [[w:Hindustan Motors|Hindustan Motors]].  

|- 

|&amp;nbsp;||INDEVESA, S.A. (Industrias Nicaraguenses De Vehiculos SA)||(?)||[[w:Nicaragua|Nicaragua]]||[[w:Bedford HA#The BTV|Pinolero]]||1974||(?)||The Nicaraguan state-owned company produced a version of GM's BTV called the Pinolero.

|-

|&amp;nbsp;||Industrias Superior||[[w:Guatemala City|Guatemala City]]||[[w:Guatemala|Guatemala]]||[[w:Bedford HA#The BTV|Chato]]||1977||1970's||A version of GM's [[w:Bedford HA#The BTV|BTV]] called the Chato was assembled in Guatemala. It was distributed by CIDEA.

|-

|3||[[w:Isuzu|Isuzu]] Kawasaki plant||[[w:Kawasaki, Kanagawa|Kawasaki, Kanagawa]]||[[w:Japan|Japan]]||[[w:Chevrolet W-Series|Chevrolet W-Series]] (1984-1998)&lt;br /&gt;[[w:GMC W-Series|GMC W-Series]] (1984-1998)&lt;br /&gt;[[w:Isuzu N-Series|Isuzu N-Series]] (1987-1994)&lt;br /&gt;[[w:Isuzu F-Series|Isuzu F-Series]] (1995-98 FRR, 1989-96 FSR, 1992-96 FTR/FVR)||1938||2005||[[w:Isuzu|Isuzu]] plant. Closed 2005.

|- 

|H&lt;br /&gt;(WMI: MPA)||[[w:Isuzu Motors (Thailand)|Isuzu Motors Co., (Thailand) Ltd.]] (IMCT)||Samrong Tai, [[w:Phra Pradaeng district|Phra Pradaeng district]], [[w:Samut Prakan province|Samut Prakan province]]||[[w:Thailand|Thailand]]||[[w:Holden Rodeo|Holden Rodeo (RA)]]||2003||2008||Rebadged Isuzu D-Max produced by Isuzu Thailand for GM Holden in Australia and New Zealand. Replaced by the updated and renamed Holden Colorado, which was made by GM Thailand rather than Isuzu Thailand. The model name was changed because after GM sold the last of its shares in Isuzu in 2006, GM Holden lost the right to use the Rodeo name, which was owned by Isuzu, during 2008.

|-

|9||[[w:KUKA|KUKA]]||[[w:Livonia, Michigan|Livonia]], [[w:Michigan|Michigan]]||United States||[[w:BrightDrop Zevo 600|BrightDrop Zevo 600]] (2022)||2021||2022||Produced under contract for GM in a limited run of less than 500 units. A temporary measure until GM's CAMI plant is ready to start building BrightDrop electric vans. 

|- 

|&amp;nbsp;||[[w:Lilpop, Rau i Loewenstein|Lilpop, Rau and Loewenstein (LRL)]]||[[w:Warsaw|Warsaw]]||[[w:Poland|Poland]]||[[w:Chevrolet|Chevrolet]] cars, trucks, and buses&lt;br /&gt;[[w:Buick|Buick]]&lt;br /&gt;[[w:Opel|Opel]]||1937||1939||Was located at Bema Street. Lilpop, Rau and Loewenstein was a GM distributor who also assembled vehicles from CKD kits under license from GM until the German invasion that began World War II interrupted production. The Germans took over the factory during the war and the company was nationalized by the Communist Polish govt. after the war.

|-

|N (Opel Speedster &amp;&lt;br /&gt;Vauxhall VX220)&lt;br /&gt;&lt;br /&gt;H (Lotus models)||[[w:Lotus Cars|Lotus Cars]]||[[w:RAF Hethel|RAF Hethel]], [[w: Hethel|Hethel]], [[w:Norfolk|Norfolk]], [[w:England|England]]||[[w:United Kingdom|United Kingdom]]||

[[w:Opel Speedster|Opel Speedster]]/[[w:Vauxhall VX220|Vauxhall VX220]] (2001-2006) 7,207 units 
 

[[w:Lotus Elise|Lotus Elise]]&lt;br /&gt;[[w:Lotus Exige|Lotus Exige]]

||2000||2005||GM owned Lotus from 1986-1993. GM sold Lotus in 1993 to A.C.B.N. Holdings S.A. of Luxembourg, a company controlled by Italian businessman Romano Artioli, who also owned Bugatti Automobili SpA. Artioli sold Lotus to Malaysian automaker [[w:Proton Holdings|Proton]] in 1996. The Opel Speedster &amp; Vauxhall VX220 were built under contract for GM by Lotus after GM had sold Lotus. The Opel Speedster &amp; Vauxhall VX220 were based on the Lotus Elise.

|- 

|6||[[w:Magna Steyr|Magna Steyr]]||[[w:Graz|Graz]]||[[w:Austria|Austria]]||[[w:Saab 9-3#Second generation (2003–2014)|Saab 9-3 Convertible]] (2004-2010)||2003||2009||Built under contract by [[w:Magna Steyr|Magna Steyr]] for GM-owned Saab Automobile AB. 9-3 Convertible production was moved to Saab's own plant in Trollhattan, Sweden in January 2010.  

|-

|&amp;nbsp;||[[w:de:McCairns Motors|McCairns Motors Ltd.]]||[[w:Dublin Docklands|Dublin Docklands]], [[w:Dublin|Dublin]] and [[w:Santry|Santry]]||[[w:Republic of Ireland|Republic of Ireland]]||[[w:Vauxhall Cresta|Vauxhall Cresta]]&lt;br /&gt;[[w:Vauxhall Victor|Vauxhall Victor]]&lt;br /&gt;[[w:Vauxhall Viva|Vauxhall Viva]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford trucks]]&lt;br /&gt;[[w:Chevrolet Bel Air|Chevrolet Bel Air]]||1935||1975||McCairns Motors was the local assembler and distributor for Vauxhall and Bedford in Ireland. Assembly began at Dublin Port on Alexandra Road in November 1935. In 1951, car assembly moved to a larger plant in Santry. McCairns also assembled and sold other brands like Simca, Alfa Romeo, and Mitsubishi Fuso. Production ended due to Ireland joining the European Economic Community in 1973 and the end of tariffs on imports of completely built-up vehicles. This removed the need for local assembly in Ireland. McCairns Motors used the site in Santry until 1987. The Omni Park shopping center now stands where the assembly plant in Santry used to be.

|-

|&amp;nbsp;||[[w:Mercury Marine|Mercury Marine]]||[[w:Stillwater, Oklahoma|Stillwater, Oklahoma]]||United States||[[w:Chevrolet small-block engine (first and second generation)#LT5|5.7L LT5 DOHC V8 engine]] (For 1990-1995 C4 Chevrolet Corvette ZR-1)||1989||1993||Engine was built for GM by Mercury Marine at their existing MerCruiser marine engine plant in Stillwater. 21,000 square feet of the 650,000 square foot plant was partitioned from the rest of the plant for assembly of this engine. LT5 engine production actually ended in 1993. Extra engines were built to be sufficient for Corvette ZR-1 production through 1995. The extra engines were sealed and crated for long-term storage and were shipped to the Corvette plant in Bowling Green, Kentucky and stored there until they were needed for installation in a '94 or '95 Corvette ZR-1. &lt;br&gt; Plant was located at 3003 N Perkins Rd. Closed in December 2011. Sold in 2012 to Belgium-based aerospace supplier Asco Industries.  

|- 

|&amp;nbsp;||Neal and Massy Industries Ltd.||[[w:Morvant|Morvant]]&lt;br /&gt; later moved to &lt;br /&gt;[[w:Arima|Arima]]||[[w:Trinidad and Tobago|Trinidad and Tobago]]||[[w:Holden Commodore#First generation (1978–1988)|Holden Commodore]]&lt;br /&gt;[[w:Holden Kingswood|Holden Kingswood]]&lt;br /&gt;[[w:Statesman (automobile)|Chevrolet Caprice (rebadged Statesman DeVille)]]&lt;br /&gt;[[w:Opel Rekord Series C|Opel Rekord]]&lt;br /&gt;[[w:Vauxhall Cresta|Vauxhall Cresta]]&lt;br /&gt;[[w:Vauxhall Victor|Vauxhall Victor]]&lt;br /&gt;[[w:Vauxhall Viva|Vauxhall Viva]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford trucks]]||1966||1994 (Production for GM may have ended earlier)||Built under license by Neal and Massy for GM. Neal and Massy also assembled vehicles for Datsun (Nissan) and Mazda. Assembly operation closed in 1994. Neal and Massy (now called Massy Motors) still operates as an importer/distributor for several non-GM automotive brands.  

|- 

|&amp;nbsp;||[[w:Nexus Automotive|Nexus Automotive (Pvt.) Ltd.]]||[[w:Port Qasim|Port Qasim]], [[w:Karachi|Karachi]], [[w:Sindh|Sindh province]]||[[w:Pakistan|Pakistan]]||[[w:Chevrolet Spark#Asia|Chevrolet Joy]]||2005||2006||Nexus Automotive was a GM licensed assembler and distributor. Built under contract for [[w:Nexus Automotive|Nexus Automotive]] by [[w:Ghandhara Nissan|Ghandhara Nissan]] at a plant with spare capacity.  

|- 

|K||[[w:Nissan USA#Manufacturing|Nissan Mexicana]]||[[w:Cuernavaca|Cuernavaca]]||[[w:Mexico|Mexico]]||[[w:Chevrolet City Express|Chevrolet City Express]] (2015-2018)&lt;br /&gt;[[w:Nissan NV200|Nissan NV200]] (2013-2021)||2014||2018||Nissan plant. 

Chevrolet City Express is a rebadged Nissan NV200 made for GM by Nissan. Chevrolet &lt;br&gt; City Express discontinued after 2018. NV200 discontinued in North America after 2021.

|-

|&amp;nbsp;||[[w:Nissan Motor Australia|Nissan Motor Australia]] Clayton plant||[[w:Clayton South, Victoria|Clayton South]], [[w:Victoria (state)|Victoria]]||[[w:Australia|Australia]]||[[w:Holden Astra#First generation (LB, LC; 1984–1987)|Holden Astra (LB/LC)]]&lt;br /&gt;[[w:Nissan Pulsar#N12 (1982)|Nissan Pulsar (N12)]]&lt;br /&gt;[[w:Holden Astra#Second generation (LD; 1987–1989)|Holden Astra (LD)]]&lt;br /&gt;[[w:Nissan Pulsar#N13 (1986)|Nissan Pulsar (N13)]]||1984 (GM prod.)||1989 (GM prod.)|| Production for GM Holden at Nissan's Australian plant was done as part of the Australian government's [[w:Button car plan|Button car plan]] for rationalization of local automotive production. The relationship ended in 1989 and GM Holden established a joint venture with Toyota called [[w:United Australian Automobile Industries|United Australian Automobile Industries]] to replace the Nissan relationship. The Nissan Pulsar-based Holden Astra was replaced by the Toyota Corolla-based Holden Nova. Nissan closed its Australian vehicle assembly plant in 1992. The Clayton plant was later taken over by HSV and the Walkinshaw Group. 

|- 

|Y||[[w:Nissan Motor Ibérica|Nissan Motor Ibérica]]||[[w:Barcelona|Barcelona]]||[[w:Spain|Spain]]||[[w:Opel Vivaro A|Opel/Vauxhall Vivaro A]] (high roof versions only)&lt;br /&gt;[[w:Renault Trafic#Second generation (X83; 2001)|Renault Trafic]] (high roof versions only)&lt;br /&gt;[[w:Renault Trafic#Second generation (X83; 2001)|Nissan Primastar]] (high roof versions only)||2001||2015||This is a Nissan plant that built high roof versions of Renault-designed midsize vans for Opel/Vauxhall as part of a supply deal between GM Europe &amp; Renault as well as for Renault and Nissan. The low roof versions were made by Vauxhall at the IBC Vehicles/GMM Luton plant however that UK plant could not fit the high roof versions so they were built by Nissan in Spain. Van production in Barcelona ended in 2015 and high roof Opel/Vauxhall Vivaro production was moved to Renault's plant in Sandouville, France, which also handled all Renault Trafic and Nissan NV300 (Primastar replacement) production. Nissan closed this plant in Dec. 2021. 

|- 

|&amp;nbsp;||[[w:de:O’Shea’s Limited (Opel)|O’Shea’s Limited]]||[[w:Cork (city)|Cork]], [[w:Munster|Munster]]||[[w:Republic of Ireland|Republic of Ireland]]||[[w:Opel|Opel]] cars including [[w:Opel Rekord|Rekord]]||1937||1965|| Before 1962, O’Shea’s was the sole Opel assembler and distributor in Ireland. From 1962-1965, assembly and distribution of Opels in Ireland was split between Reg Armstrong Motors and O’Shea’s Limited. After 1965, Reg Armstrong Motors was the sole Opel assembler and distributor in Ireland. 

|-

|&amp;nbsp;||PT. Pantja Motor||[[w:Sunter, Jakarta|Sunter]], [[w:North Jakarta|North Jakarta]], [[w:Jakarta|Jakarta]]||[[w:Indonesia|Indonesia]]||[[w:Chevrolet Tavera|Chevrolet Tavera]]||2001||2005||Isuzu's Indonesian assembler, now known as [[w:Isuzu Astra Motor Indonesia|Isuzu Astra Motor Indonesia]]. Built the Isuzu Panther-based Tavera for GM Indonesia.  

|- 

|&amp;nbsp;||[[w:Pininfarina|Pininfarina]]||[[w:Grugliasco|Grugliasco]]||[[w:Italy|Italy]]||[[w:Cadillac Eldorado#1959–60 Eldorado Brougham|Cadillac Eldorado Brougham (Series 6900)]] (1959-1960) painted bodies||1959||1960||Bodies were built by [[w:Pininfarina|Pininfarina]] and mated with chassis shipped to Italy by Cadillac and then shipped back to the US. 

|- 

|&amp;nbsp;||[[w:Pininfarina|Pininfarina]]||[[w:San Giorgio Canavese|San Giorgio Canavese]]||[[w:Italy|Italy]]||[[w:Cadillac Allanté|Cadillac Allanté]] (1987-1993) painted bodies||1986||1993||Bodies were designed and manufactured under contract by [[w:Pininfarina|Pininfarina]] for Cadillac. Plant was built specially for the Allanté. Bodies were then flown from Turin, Italy to Detroit on specially equipped Boeing 747s and then trucked to GM's Detroit/Hamtramck Assembly Plant for final assembly. The assembly process was known as the &quot;Allanté Air Bridge&quot;. It was also referred to as &quot;the world's longest assembly line.&quot;

|- 

|&amp;nbsp;||[[w:Pragoti|Pragoti Industries Ltd.]]||[[w:Sitakunda|Sitakunda]], [[w:Chittagong Division|Chittagong Division]]||[[w:Bangladesh|Bangladesh]]||[[w:Vauxhall Viva|Vauxhall Viva]]&lt;br /&gt;[[w:Bedford Vehicles|Bedford trucks and buses]]&lt;br /&gt;[[w:Bedford HA#The BTV|BTV]]||1966||1970's||Began as part of [[w:Ghandhara Industries|Ghandhara Industries]] Ltd. in 1966 when Bangladesh was still [[w:East Pakistan|East Pakistan]] and assembled GM vehicles like the Ghandhara plant in Karachi did. After Bangladesh became independent in 1971, the operation was nationalized by the new government and became Pragoti Industries Ltd.  

|- 

|&amp;nbsp;||[[w:de:Reg. Armstrong Motors|Reg Armstrong Motors Ltd.]]||[[w:Ringsend|Ringsend]], [[w:Dublin|Dublin]]||[[w:Republic of Ireland|Republic of Ireland]]||[[w:Opel|Opel]] cars including [[w:Opel Kadett|Kadett]], [[w:Opel Rekord|Rekord]], and [[w:Opel Commodore|Commodore]]||1962||1974||From 1962-1965, assembly and distribution of Opels in Ireland was split between Reg Armstrong Motors and O’Shea’s Limited. After 1965, Reg Armstrong Motors was the sole Opel assembler and distributor in Ireland. Reg Armstrong Motors also assembled the [[w:NSU Prinz|NSU Prinz]], [[w:Honda motorcycles|Honda motorcycles]], and from 1976-1978, the original [[w:Mini|Mini]] at the Ringsend plant. Production ended due to Ireland joining the European Economic Community in 1973 and the end of tariffs on imports of completely built-up vehicles. This removed the need for local assembly in Ireland. 

|-

|B (GM)||[[w:Société de Véhicules Automobiles de Batilly|Renault Batilly]]||[[w:Batilly, Meurthe-et-Moselle|Batilly]]||[[w:France|France]]||[[w:Renault Trafic#First generation (1980)|Opel/Vauxhall Arena]]&lt;br /&gt;[[w:Renault Trafic#First generation (1980)|Renault Trafic]]&lt;br /&gt;[[w:Renault Master#Second generation (1997)|Opel/Vauxhall Movano A]]&lt;br /&gt;[[w:Renault Master#Third generation (2010)|Opel/Vauxhall Movano B]]&lt;br /&gt;[[w:Renault Master|Renault Master]]&lt;br /&gt;[[w:Renault Master#Renault Mascott|Renault Trucks Mascott]]&lt;br /&gt;[[w:Nissan Interstar|Nissan Interstar]]&lt;br /&gt;[[w:Nissan NV400|Nissan NV400]]||1997||2017||Renault-[[w:Société de Véhicules Automobiles de Batilly|SOVAB]] plant. Opel/Vauxhall was sold to [[w:PSA Group|PSA Group]] in 2017. As part of PSA Group, Opel/Vauxhall became part of [[w:Stellantis|Stellantis]] in 2021. Movano switched to being PSA/Fiat-based instead of Renault-based in 2021.

|- 

|S (GM)||[[w:Sandouville Renault Factory|Renault Sandouville]]||[[w:Sandouville|Sandouville]]||[[w:France|France]]||[[w:Renault Trafic#Third generation (X82; 2014)|Opel/Vauxhall Vivaro]] B (high roof versions only) &lt;br /&gt;[[w:Renault Trafic#Third generation (X82; 2014)|Renault Trafic]]&lt;br /&gt;[[w:Nissan NV300|Nissan NV300]]&lt;br /&gt;[[w:Renault Trafic#Third generation (X82; 2014)|Nissan Primastar]]&lt;br /&gt;[[w:Renault Trafic#Third generation (X82; 2014)|Fiat Talento]]||2014||2017||Renault plant. Opel/Vauxhall was sold to [[w:PSA Group|PSA Group]] in 2017. Vivaro switched to being PSA-based instead of Renault-based in 2018. As part of PSA Group, Opel/Vauxhall became part of [[w:Stellantis|Stellantis]] in 2021.

|- 

|&amp;nbsp;||[[w:Renault Argentina|Renault Santa Isabel]]||[[w:Santa Isabel, Córdoba|Santa Isabel]], [[w:Córdoba Province, Argentina|Cordoba]]||[[w:Argentina|Argentina]]||[[w:Chevrolet D-20|Chevrolet C-20 &amp; D-20]]&lt;br /&gt;[[w:Chevrolet Tahoe#First generation (1992)|Chevrolet Grand Blazer]] (GMT400)&lt;br /&gt;[[w:Chevrolet C/K#1997–2001|Chevrolet Silverado]] (GMT400)&lt;br /&gt;[[w:Renault Trafic#South America|Chevrolet Trafic/SpaceVan]] ||1991||2002||[[w:Renault Argentina|Renault Argentina]]-CIADEA plant. Built Chevrolets under license for GM. 

|- 

|&amp;nbsp;||[[w:Sevel Argentina|Sevel Argentina]]||[[w:Córdoba, Argentina|Estación Ferreyra, Córdoba]], [[w:Córdoba Province, Argentina|Cordoba]]||[[w:Argentina|Argentina]]||[[w:Chevrolet D-20|Chevrolet C-20/D-20]]||1985||1991||Fiat - PSA jointly owned plant. Built Chevrolets under license for GM. 

|- 

|For Saab&lt;br&gt; 9-2X:&lt;br&gt; G (w/man. trans.),&lt;br&gt; H (w/auto. trans.)||[[w:Subaru#Manufacturing facilities|Subaru Main Plant]]||[[w:Ōta, Gunma|Ōta, Gunma]]||[[w:Japan|Japan]]||[[w:Saab 9-2X|Saab 9-2X]] (2005-2006)&lt;br /&gt;[[w:Subaru Forester#Second generation (SG; 2002)|Chevrolet Forester (India)]] (2003-2007)||2003 (GM prod.)||2007 (GM prod.)||[[w:Subaru|Subaru]] plant 

|- 

|4||[[w:Subaru-Isuzu Automotive|Subaru-Isuzu Automotive]] (S.I.A.)||[[w:Lafayette, Indiana|Lafayette, Indiana]]||United States||[[w:Holden Frontera#Second generation (1998)|Holden Frontera]] (UE/MX)||1999 (GM prod.)||2003 (GM prod.)||Subaru &amp; Isuzu joint venture plant. Isuzu built a rebadged, rhd version of the 2nd generation US market Isuzu Rodeo &amp; Amigo SUVs for export to GM Holden in Australia and New Zealand.

|-

|W (GM),&lt;br /&gt;4 (Suzuki)||Suzuki Iwata Assembly||[[w:Iwata, Shizuoka|Iwata, Shizuoka]]||[[w:Japan|Japan]]||[[w:Chevrolet Tracker (Americas)#First generation|Geo Tracker]] (US: 1989-1990)&lt;br /&gt;[[w:Suzuki Sidekick|Suzuki Sidekick]] (US: 1989-1995, 1997-98)&lt;br /&gt;[[w:Suzuki Sidekick|Suzuki Sidekick Sport]] (US: 1996-1998)&lt;br /&gt;[[w:Suzuki Grand Vitara|Suzuki Grand Vitara]] (1999-2013)&lt;br /&gt;[[w:Suzuki XL-7#First generation (XL-7; 1998)|Suzuki XL-7]] (2001-2006)&lt;br /&gt;[[w:Holden Drover#Second generation (1981)|Holden Drover (QB)]]&lt;br /&gt;[[w:Holden Scurry#Eighth generation (DA71/DB71/DA81/DA41/DB41/DA51/DB51; 1985)|Holden Scurry (NB)]]||1985 (GM prod.)||1990 (GM prod.)||[[w:Suzuki|Suzuki]] plant 

|- 

|K (GM),&lt;br /&gt;5 (Suzuki)||Suzuki Kosai Assembly||[[w:Kosai, Shizuoka|Kosai, Shizuoka]]||[[w:Japan|Japan]]||[[w:Chevrolet Sprint|Chevrolet Sprint]] (US: 1985-1988)&lt;br /&gt;[[w:Geo Metro|Geo Metro]] (US: 1989-1993)&lt;br /&gt;[[w:Pontiac Firefly|Pontiac Firefly]] (Canada)&lt;br /&gt;[[w:Holden Barina#First generation (MB, ML; 1985–1988)|Holden Barina (MB/ML)]]&lt;br /&gt;[[w:Holden Barina#Second generation (MF, MH; 1989–1994|Holden Barina (MF/MH)]]&lt;br /&gt;[[w:Suzuki Cultus|Suzuki Swift]] (US: 1989-1994)&lt;br /&gt;[[w:Suzuki Ignis#Chevrolet Cruze|Chevrolet/Holden Cruze (YGM1)]] (YG) ||1984 (GM prod.)||2008 (GM prod.)||[[w:Suzuki|Suzuki]] plant 

|- 

|M (GM),&lt;br /&gt;0 (Suzuki/Fiat/Subaru)||[[w:Magyar Suzuki Corporation|Magyar Suzuki Corporation]]||[[w:Esztergom|Esztergom]]||[[w:Hungary|Hungary]]||[[w:Opel Agila#Second generation (H08; 2007)|Opel/Vauxhall Agila B]]&lt;br /&gt;[[w:Suzuki Splash|Suzuki Splash]]&lt;br /&gt;[[w:Suzuki Swift|Suzuki Swift]]&lt;br /&gt;[[w:Suzuki Cultus#Second generation (1988)|Subaru Justy]]&lt;br /&gt;[[w:Suzuki SX4|Suzuki SX4]]&lt;br /&gt;[[w:Fiat Sedici|Fiat Sedici]]&lt;br /&gt;[[w:Suzuki Ignis#Suzuki Ignis (2003 facelift)|Suzuki Ignis]]&lt;br /&gt;[[w:Suzuki Ignis#Suzuki Ignis (2003 facelift)|Subaru G3X Justy]]||1992&lt;br /&gt;&lt;br /&gt;2007 (GM prod.)||2014 (GM prod.)||[[w:Suzuki|Suzuki]] plant 

|- 

|&amp;nbsp;||Suzuki Sagara Assembly &amp; Engine||[[w:Makinohara|Makinohara]], [[w:Shizuoka Prefecture|Shizuoka Prefecture]]||[[w:Japan|Japan]]||[[w:Chevrolet MW|Chevrolet MW]] (sold in Japan)&lt;br /&gt;||2000||2010||[[w:Suzuki|Suzuki]] plant.&lt;br /&gt; Also built the 3.6-liter GM High Feature V6 engine ([[w:GM High Feature engine#LY7|Suzuki N36A]]) to power the [[w:Suzuki XL-7#Second generation (XL7; 2006)|2nd generation Suzuki XL7]] under license from GM. (Note: Dates reflect beginning &amp; end dates of production for GM.)  

|- 

|&amp;nbsp;||Tecna SA||[[w:Arica, Chile|Arica]]||[[w:Chile|Chile]]||[[w:Acadian (automobile)|Acadian]] (1962-71 from CKD kits supplied by GM Oshawa and Willow Run)&lt;br /&gt;[[w:Beaumont (automobile)|Acadian Beaumont]] (1964-71 from CKD kits supplied by GM Oshawa)&lt;br /&gt;[[w:Vauxhall Victor|Vauxhall Victor]]||1962||1971||  

|- 

|&amp;nbsp;||Tecno S.A.||[[w:Uruca|La Uruca]], [[w:San José, Costa Rica|San José]]||[[w:Costa Rica|Costa Rica]]||[[w:Bedford HA#The BTV|GM Amigo]]||1970s||(?)||A version of GM's [[w:Bedford HA#The BTV|BTV]] called the Amigo was assembled in Costa Rica.

|-

|&amp;nbsp;||Tecnomotor S.A.||(?)||[[w:Paraguay|Paraguay]]||[[w:Bedford HA#The BTV|GM Mitai]]||1970s||(?)||A version of GM's [[w:Bedford HA#The BTV|BTV]] called the Mitai was assembled in Paraguay.

|-

|9 (GM),&lt;br /&gt;6 (Fiat &amp; Ram)||[[w:Tofaş|Tofaş]]||[[w:Bursa|Bursa]]||[[w:Turkey|Turkey]]||[[w:Opel Combo#Combo D (2012-2018)|Opel/Vauxhall Combo D]]&lt;br /&gt;[[w:Fiat Doblo|Fiat Doblo]]&lt;br /&gt;[[w:Ram ProMaster City|Ram ProMaster City]]||2011||2017||[[w:Fiat|Fiat]] plant (joint venture with Koç Holding of Turkey). Opel/Vauxhall was sold to PSA Group in 2017. Combo switched to being PSA-based instead of Fiat-based in 2019. As part of PSA Group, Opel/Vauxhall became part of Stellantis in 2021. Fiat and Tofaş also became part of Stellantis in 2021. 

|- 

|&amp;nbsp;||[[w:Toyota Australia|Toyota Australia]] [[w:Toyota Australia Altona Plant|Altona plant]]||[[w:Altona North|Altona North]], [[w:Victoria (state)|Victoria]]||[[w:Australia|Australia]]||[[w:Holden Nova#Second generation (LG; 1994–1996)|Holden Nova (LG)]]&lt;br /&gt;[[w:Toyota Corolla (E100)|Toyota Corolla (E100)]]&lt;br /&gt;[[w:Holden Apollo|Holden Apollo (JM/JP)]]&lt;br /&gt;[[w:Toyota Camry (XV10)|Toyota Camry (XV10)]]||1994||1996 (GM prod.)|| Production for GM Holden at Toyota's Australian plant was done as part of [[w:United Australian Automobile Industries|United Australian Automobile Industries]], a model sharing joint venture in Australia between Holden and Toyota from 1987-1996. This was created as part of the Australian government's [[w:Button car plan|Button car plan]] for rationalization of local automotive production. Toyota consolidated its Australian production at the new Altona plant in 1994-1995. The joint venture dissolved in 1996 and Holden's rebadged Toyotas were replaced with rebadged Opel models (Astra and Vectra) from GM Europe. Corolla production in Australia ended in 1999. Toyota closed the Altona plant in 2017.

|-

|&amp;nbsp;||[[w:Toyota Australia|Toyota Australia]] Port Melbourne plant||[[w:Port Melbourne|Port Melbourne]], [[w:Victoria (state)|Victoria]]||[[w:Australia|Australia]]||[[w:Holden Apollo|Holden Apollo (JK/JL)]]&lt;br /&gt;[[w:Toyota Camry#V20 (1986–1992)|Toyota Camry (V20)]]&lt;br /&gt;[[w:Holden Apollo|Holden Apollo (JM)]]&lt;br /&gt;[[w:Toyota Camry (XV10)|Toyota Camry (XV10)]]||1989 (GM prod.)||1994 (GM prod.)|| Production for GM Holden at Toyota's Australian plant was done as part of [[w:United Australian Automobile Industries|United Australian Automobile Industries]], a model sharing joint venture in Australia between Holden and Toyota from 1987-1996. This was created as part of the Australian government's [[w:Button car plan|Button car plan]] for rationalization of local automotive production. Toyota consolidated its Australian production at the new Altona plant in 1994-1995 and production ended at the older Port Melbourne plant in late 1994. The joint venture would later dissolve in 1996 and Holden's rebadged Toyota Camry was replaced with a rebadged Opel Vectra from GM Europe.

|-

|&amp;nbsp;||PT. Udatin (Usaha Dagang Teknik Indonesia)||[[w:Surabaya|Surabaya]], [[w:East Java|East Java]]||[[w:Indonesia|Indonesia]]||[[w:Holden FC|Holden FC]]&lt;br /&gt;[[w:Holden FB|Holden FB]]&lt;br /&gt;[[w:Holden EK|Holden EK]]&lt;br /&gt;[[w:Holden EJ|Holden EJ]]&lt;br /&gt;[[w:Holden EH|Holden EH]]&lt;br /&gt;[[w:Holden HQ|Holden HQ]]&lt;br /&gt;[[w:Holden HJ|Holden HJ]]&lt;br /&gt;[[w:Holden HX|Holden HX]]&lt;br /&gt;[[w:Holden HZ|Holden HZ]]&lt;br /&gt;[[w:Statesman (automobile)|Statesman brand HQ-HZ]]&lt;br /&gt;[[w:Holden Monaro|Holden Monaro]] HQ&lt;br /&gt;[[w:Holden Torana|Holden Torana]] LJ, LH, LX&lt;br /&gt; [[w:Holden Gemini#First generation|Holden Gemini TX, TC, TD, TE, TF, TG]]&lt;br /&gt;[[w:Holden Camira|Holden Camira]] JB&lt;br /&gt;[[w:Isuzu Aska#South-East Asia and New Zealand|Holden Aska]]&lt;br /&gt;[[w:Holden Gemini#Second generation|Holden Gemini (RB)]]&lt;br /&gt;[[w:Holden Commodore (VB)|Holden Commodore (VB)]]&lt;br /&gt;[[w:Holden Commodore (VC)|Holden Commodore (VC)]]&lt;br /&gt;[[w:Holden Commodore (VH)|Holden Commodore (VH)]]&lt;br /&gt;[[w:Holden Commodore (VK)|Holden Commodore (VK)]]&lt;br /&gt;[[w:Holden Commodore (VL)|Holden Calais (VL)]]&lt;br /&gt;[[w:Isuzu Faster#Second generation (1980–1988)|Holden Lincah/Raider]]&lt;br /&gt;[[w:GMC (automobile)|GMC trucks]]||1959||1988||Built vehicles under contract for GM. During the 1960's, production was off and on due to Indonesian government policies and the economic situation. Production ended in 1988. 

|- 

|&amp;nbsp;||Unison||[[w:Minsk|Minsk]]||[[w:Belarus|Belarus]]||[[w:Chevrolet Tahoe#Fourth generation (2015)|Chevrolet Tahoe]] K2XX, [[w:Chevrolet Trax|Chevrolet Tracker]], [[w:Cadillac Escalade#Fourth generation (2015)|Cadillac Escalade]] K2XX, [[w:Opel Mokka#First generation (J13; 2012)|Opel Mokka]]||2015||2018||Built under contract by Unison for GM. Production ended in 2018.  

|- 

|6,7 (Saab)&lt;br /&gt;9 (Opel/Vauxhall)||[[w:Valmet Automotive|Valmet Automotive]]||[[w:Uusikaupunki|Uusikaupunki]]||[[w:Finland|Finland]]||[[w:Saab 9-3#First generation (1998–2003)|Saab 9-3 Convertible &amp; 9-3 Viggen]]&lt;br /&gt;[[w:Saab 900|Saab 900]] (including 900 Convertible)&lt;br /&gt;[[w:Opel Calibra|Opel/Vauxhall Calibra]]||1969||2003||Built under contract by [[w:Valmet Automotive|Valmet Automotive]] for Saab &amp; for Opel/Vauxhall. Saab-Valmet was established in 1968 as a joint venture between Valmet and Saab-Scania. In 1992, Valmet became the sole owner, and the company was renamed Valmet Automotive in 1995.  

|- 

|X||[[w:ZAZ|ZAZ]]||[[w:Zaporizhia|Zaporizhia]] &amp; [[w:Illichivsk|Illichivsk]]||[[w:Ukraine|Ukraine]]||[[w:Chevrolet Aveo (T200)|Chevrolet Aveo]], [[w:Chevrolet Lacetti|Chevrolet Lacetti]], [[w:Chevrolet Lanos|Chevrolet Lanos]], [[w:Opel Astra#G|Opel Astra Classic]], [[w:Opel Astra#H|Opel Astra]], [[w:Opel Corsa|Opel Corsa]], [[w:Opel Combo|Opel Combo]], [[w:Opel Meriva|Opel Meriva]], [[w:Opel Vectra|Opel Vectra]], [[w:Opel Zafira|Opel Zafira]]||2003||2012||Built under contract by [[w:ZAZ|ZAZ]] for GM.  

|- 

|}</text>
      <sha1>em697igziv1onwlvjqee0y5vovsltze</sha1>
    </revision>
  </page>
  <page>
    <title>The Linux Kernel/Multitasking/Real-time</title>
    <ns>0</ns>
    <id>470358</id>
    <revision>
      <id>4657031</id>
      <parentid>4654538</parentid>
      <timestamp>2026-08-10T12:46:49Z</timestamp>
      <contributor>
        <username>Conan</username>
        <id>3188</id>
      </contributor>
      <minor />
      <comment>perf-intel-pt</comment>
      <origin>4657031</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="15347" sha1="et1b8qso6jcqjt4l73eekd6ohh9xozu" xml:space="preserve">&lt;noinclude&gt;
{{DISPLAYTITLE:Real-time Linux}}
&lt;/noinclude&gt;

==== RT preemption ====

[https://wiki.linuxfoundation.org/realtime/start The Linux Foundation's Real-Time Linux (RTL) collaborative project] is focused on improving the real-time capabilities of Linux and advancing the adoption of real-time Linux in various industries, including aerospace, automotive, robotics, and telecommunications.

Parameter {{The Linux Kernel/id|CONFIG_PREEMPT_RT}} enables real-time preemption.

==== RT scheduling policies ====

Scheduling policies for RT:
: {{The Linux Kernel/id|SCHED_FIFO}}, {{The Linux Kernel/id|SCHED_RR}}
:: implemented in {{The Linux Kernel/source|kernel/sched/rt.c}}
: {{w|SCHED_DEADLINE}}
:: implemented in {{The Linux Kernel/source|kernel/sched/deadline.c}}


API:
: {{The Linux Kernel/man|1|chrt}} &amp;ndash; manipulate the real-time attributes of a process
: {{The Linux Kernel/man|2|sched_rr_get_interval}} &amp;ndash; get the SCHED_RR interval for the named process
: {{The Linux Kernel/man|2|sched_setscheduler}}, sched_getscheduler &amp;ndash; set and get scheduling policy/parameters
: {{The Linux Kernel/man|2|sched_get_priority_min}}, sched_get_priority_max &amp;ndash; get static priority range

RT scheduler tunables:
: /proc/sys/kernel/sched_rt_period_us &amp;ndash; period over which RT task bandwidth is measured (default 1000000 µs = 1 s)
: /proc/sys/kernel/sched_rt_runtime_us &amp;ndash; maximum time RT tasks may consume per period (default 950000 µs); set to -1 to disable the RT bandwidth limit
: /sys/kernel/realtime &amp;ndash; indicates the running kernel has PREEMPT_RT enabled (present only on RT kernels)
: /sys/devices/system/clocksource/clocksource0/current_clocksource &amp;ndash; active clocksource, critical for RT timing accuracy

🛠️ Utilities
: [https://git.kernel.org/pub/scm/utils/tuna/tuna.git/ tuna] &amp;ndash; view and change thread attributes (affinity, scheduling policy, priority)
:: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/latest/html/monitoring_and_managing_system_status_and_performance/reviewing-a-system-by-using-the-tuna-interface RHEL tuna guide]
: [https://github.com/sosreport/sos/blob/main/sos/report/plugins/kernelrt.py sos kernelrt plugin] &amp;ndash; diagnostics collection for RT kernel

{{w|Priority inversion}} occurs when a high-priority task blocks on a resource held by a low-priority task, while a medium-priority task preempts the low-priority one indefinitely.
The kernel mitigates this with {{The Linux Kernel/id|rt_mutex}} which implements {{w|Priority inheritance}} &amp;ndash; temporarily boosting the lock holder's priority to that of the highest-priority waiter.

==== RT synchronization ====

⚲ APIs
: {{The Linux Kernel/id|migrate_disable}} + {{The Linux Kernel/id|spin_lock}}
: {{The Linux Kernel/id|local_lock}} calls migrate_disable(); {{The Linux Kernel/id|rt_spin_lock}}({{The Linux Kernel/id|this_cpu_ptr}}((__lock)));

📖 References
: [https://docs.kernel.org/locking/locktypes.html#:~:text=migrate_disable Usage of migrate_disable]
: {{The Linux Kernel/doc|PREEMPT_RT caveats: spinlock_t, rwlock_t, migrate_disable and local_lock|locking/locktypes.html#spinlock-t-and-rwlock-t}}


⚙️ Internals

Spinlock 
: {{The Linux Kernel/include|linux/spinlock_rt.h}} used via {{The Linux Kernel/include|linux/spinlock_types.h}}
:: {{The Linux Kernel/id|spinlock_t}}
::: {{The Linux Kernel/id|rt_mutex_base}}
::: {{The Linux Kernel/id|rt_spin_lock}} ...
:::: {{The Linux Kernel/id|__rt_spin_lock}} ...
::::: {{The Linux Kernel/id|rtlock_lock}} ...
: {{The Linux Kernel/source|kernel/locking/spinlock_rt.c}} &amp;ndash; RT-aware spinlock implementation

RT Mutex
: {{The Linux Kernel/include|linux/rtmutex.h}} used via {{The Linux Kernel/include|linux/mutex_types.h}}
:: {{The Linux Kernel/id|rt_mutex_base}}
:: {{The Linux Kernel/id|rt_mutex}}
::: {{The Linux Kernel/id|rt_mutex_lock}} ...
: {{The Linux Kernel/source|kernel/locking/rtmutex_api.c}} &amp;ndash; RT mutex kernel API
: {{The Linux Kernel/source|kernel/locking/rtmutex_common.h}} &amp;ndash; RT mutex internal definitions
: {{The Linux Kernel/source|kernel/locking/rtmutex.c}} &amp;ndash; RT mutex core with priority inheritance

rwbase_rt
: {{The Linux Kernel/include|linux/rwbase_rt.h}} used via {{The Linux Kernel/include|linux/rwlock_types.h}}
:: {{The Linux Kernel/id|rwlock_t}}
::: {{The Linux Kernel/id|rwbase_rt}} &amp;ndash; used to implement real-time read/write locks
::: {{The Linux Kernel/id|rt_read_trylock}} ...
: {{The Linux Kernel/source|kernel/locking/rwbase_rt.c}} &amp;ndash; RT rw_semaphore/rwlock base
: {{The Linux Kernel/source|kernel/locking/spinlock_rt.c}} &amp;ndash; RT-aware spinlock implementation

==== Testing RT capabilities ====

The testing process for Real-Time Linux typically involves several key aspects.
First and foremost, it is crucial to verify the accuracy and stability of the system's timekeeping mechanisms.
Precise time management is fundamental to real-time applications, and any inaccuracies can lead to timing errors and compromise the system's real-time capabilities.

Another essential aspect of testing is evaluating the system's scheduling algorithms.
Real-Time Linux employs advanced scheduling policies to prioritize critical tasks and ensure their timely execution.
Testing the scheduler involves assessing its ability to allocate resources efficiently, handle task prioritization correctly, and prevent resource contention or priority inversion scenarios.

Furthermore, latency measurement is a critical part of Real-Time Linux testing.
Latency refers to the time delay between the occurrence of an event and the system's response to it.
In real-time applications, minimizing latency is crucial to achieving timely and predictable behavior.
Testing latency involves measuring the time it takes for the system to respond to various stimuli and identifying any sources of delay or unpredictability.

Additionally, stress testing plays a significant role in assessing the system's robustness under heavy workloads.
It involves subjecting the Real-Time Linux system to high levels of concurrent activities, intense computational loads, and input/output operations to evaluate its performance, responsiveness, and stability.
Stress testing helps identify potential bottlenecks, resource limitations, or issues that might degrade the real-time behavior of the system.

===== RTLA =====
: [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/rtla RTLA – The realtime Linux analysis tool]: 
:: {{The Linux Kernel/doc|rtla timerlat|tools/rtla/rtla-timerlat.html}} &amp;ndash; CLI for the kernel's {{The Linux Kernel/doc|timerlat tracer|trace/timerlat-tracer.html}} 
:: {{The Linux Kernel/doc|rtla osnoise|tools/rtla/rtla-osnoise.html}} &amp;ndash; CLI for the kernel's {{The Linux Kernel/doc|osnoise tracer|trace/osnoise-tracer.html}}.
::: Kernel function {{The Linux Kernel/id|run_osnoise}} measures time with function {{The Linux Kernel/id|trace_clock_local}} in loop.
:: {{The Linux Kernel/doc|rtla hwnoise|tools/rtla/rtla-hwnoise.html}} &amp;ndash; CLI for the {{The Linux Kernel/doc|osnoise tracer|trace/osnoise-tracer.html}} with interrupts disabled
::: Implementation: {{The Linux Kernel/source|tools/tracing/rtla}} and {{The Linux Kernel/source|kernel/trace/trace_osnoise.c}}
:: [https://bristot.me/linux-scheduling-latency-debug-and-analysis/ Linux scheduling latency debug and analysis]

===== RT-Tests =====
: [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/rt-tests RT-Tests], [https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/tree/src/ source], [https://gitlab.com/linux-kernel/rt-tests @gitlab]
:: [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start cyclictest]
: some RT-Tests man pages:
:: [https://man.archlinux.org/man/cyclictest.8.en cyclictest] &amp;ndash; measures {{The Linux Kernel/man|2|clock_nanosleep}} or {{The Linux Kernel/man|2|nanosleep}} delay
&lt;!-- generated with 
grep -h ' \\- ' ./rt-tests/src/*/*.[0-9] | sed 's#^#:: #;s#\\f.##g;s#\([^ ]\+\) \\-#[https://man.archlinux.org/man/\1.8.en \1] \–#'
--&gt;
:: [https://man.archlinux.org/man/hwlatdetect.8.en hwlatdetect] &amp;ndash; CLI for {{The Linux Kernel/doc|/sys/kernel/tracing/hwlat_detector|trace/hwlat_detector.html}} / {{The Linux Kernel/source|kernel/trace/trace_hwlat.c}}. Kernel function {{The Linux Kernel/id|kthread_fn}} measures time delays with function {{The Linux Kernel/id|trace_clock_local}} in loop.
:: [https://man.archlinux.org/man/oslat.8.en oslat] &amp;ndash; measures delay with {{w|Time_Stamp_Counter|RDTSC}} in busy loop
:: [https://man.archlinux.org/man/hackbench.8.en hackbench] &amp;ndash; scheduler benchmark/stress test

===== ftrace =====

Testing latencies with the ftrace - Function Tracer.
: [https://docs.kernel.org/trace/ftrace.html#:~:text=tracing_max_latency tracing_max_latency]
: the {{The Linux Kernel/doc|irqsoff|trace/ftrace.html#irqsoff}}, {{The Linux Kernel/doc|preemptoff|trace/ftrace.html#preemptoff}}, {{The Linux Kernel/doc|preemptirqsoff|trace/ftrace.html#preemptirqsoff}} tracers
: {{The Linux Kernel/source|tools/tracing/latency}} &amp;ndash; latency measurement tools
: {{The Linux Kernel/id|CONFIG_IRQSOFF_TRACER}} &amp;ndash; interrupts-off latency tracer
: {{The Linux Kernel/id|CONFIG_PREEMPT_TRACER}} &amp;ndash; preemption-off latency tracer
: {{The Linux Kernel/id|CONFIG_SCHED_TRACER}} &amp;ndash; scheduling latency tracer

===== Other tests =====
: {{The Linux Kernel/man|1|perf-intel-pt}} – {{w|Intel Processor Trace}} for low-overhead instruction-level tracing, {{The Linux Kernel/source|tools/perf/Documentation/perf-intel-pt.txt}}
: [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/rtla/processor_trace Using rtla with perf processor trace]
: [https://github.com/xzpeter/rt-trace-bpf RT Tracing Tools with eBPF]
: {{The Linux Kernel/ltp||realtime}}
: https://www.latencytop.org/, {{The Linux Kernel/source|kernel/latencytop.c}}
: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/latest/html/optimizing_rhel_for_real_time_for_low_latency_operation/using-the-rteval-container-for-real-time-task-execution rteval] &amp;ndash; RT workload and latency evaluation in a container


==== RT optimizations ====
: {{The Linux Kernel/id|CONFIG_PSI_DEFAULT_DISABLED}} &amp;ndash; disable {{The Linux Kernel/doc|PSI|accounting/psi.html}}
:: Check: &lt;code&gt;ls /proc/pressure/&lt;/code&gt; should fail


==== ... ====

📚 Further reading:
: https://lore.kernel.org/linux-rt-users/
: https://lore.kernel.org/linux-trace-kernel/


📖 References
: {{The Linux Kernel/doc|Real-time preemption|core-api/real-time/index.html}}
: {{The Linux Kernel/doc|Documentation for /proc/sys/kernel/|admin-guide/sysctl/kernel.html}} &amp;ndash; sched_rt_period_us, sched_rt_runtime_us
: https://realtime-linux.org/
:: [https://realtime-linux.org/getting-started-with-preempt_rt-guide/ Getting Started with PREEMPT_RT Guide]
:: [https://realtime-linux.org/a-checklist-for-real-time-applications-in-linux/ A Checklist for Real-Time Applications in Linux]
: [https://wiki.linuxfoundation.org/realtime/start the Real-Time Linux wiki]
:: [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cpu-partitioning/start CPU partitioning and isolation]
: [https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git linux-stable-rt.git]
: [https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/log/?h=for-kbuild-bot/current-stable linux-rt-devel.git]


📚 Further reading about real-time Linux:
: [https://lpc.events/event/19/contributions/2264/ News from PREEMPT_RT] &amp;ndash; LPC 2025, post-mainline developments
: https://deepwiki.com/torvalds/linux/2.1-process-scheduler
: [https://www.youtube.com/watch?v=x6g15nRGpAM Introduction to Real-Time Linux: Unleashing Deterministic Computing]
: [https://www.youtube.com/playlist?list=PL0fKordpLTjKsBOUcZqnzlHShri4YBL1H Power Management and Scheduling in the Linux Kernel (OSPM)]
: [https://lwn.net/Kernel/Index/#Realtime Realtime@LWN]
: [https://wiki.archlinux.org/title/Realtime_kernel_patchset Realtime kernel patchset, Arch Linux]
: https://www.kernel.org/pub/linux/kernel/projects/rt/ - RT patches for upstream kernel
: {{w|High Precision Event Timer}} (HPET)
: [https://bristot.me/demystifying-the-real-time-linux-latency/ Demystifying the Real-Time Linux Scheduling Latency]
: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/latest RHEL for RT]
:: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/latest/html/understanding_rhel_for_real_time/index Understanding RHEL for RT] &amp;ndash; affinity, SCHED_DEADLINE cpusets, RT socket options, timerlat, runtime monitors
:: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/latest/html/optimizing_rhel_for_real_time_for_low_latency_operation/index Optimizing for low latency]:
::: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/latest/html/optimizing_rhel_for_real_time_for_low_latency_operation/scheduling-policies-for-rhel-for-real-time SCHED_DEADLINE parameters]
::: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/latest/html/optimizing_rhel_for_real_time_for_low_latency_operation/setting-bios-parameters-for-system-tuning BIOS tuning] &amp;ndash; disable power management, error correction, SMI
::: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/latest/html/optimizing_rhel_for_real_time_for_low_latency_operation/runtime-verification-of-the-real-time-kernel Runtime verification] &amp;ndash; monitors and reactors
::: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/latest/html/optimizing_rhel_for_real_time_for_low_latency_operation/isolating-cpus-using-tuned-profiles-real-time CPU isolation] &amp;ndash; tuned profiles, isolated_cores, nohz_full
::: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/latest/html/optimizing_rhel_for_real_time_for_low_latency_operation/improving-cpu-performance-by-using-rcu-callbacks RCU callback offloading]
::: [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/latest/html/optimizing_rhel_for_real_time_for_low_latency_operation/scheduling-problems-on-the-real-time-kernel-and-solutions Scheduling problems] &amp;ndash; throttling, starvation
: Linux subsystems related to real-time
:: {{w|Linux kernel#Scheduling and preemption|Linux kernel scheduling and preemption}}
:: [[The_Linux_Kernel/Multitasking#Interrupts|Interrupts]]
:: [[The_Linux_Kernel/Multitasking#Deferred_works|Deferred works]]
:: [https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-6.html Non-maskable interrupt handler] (NMI)
:: [https://wiki.linuxfoundation.org/realtime/documentation/howto/debugging/smi-latency/smi System management interrupt] (SMI)
:: {{The Linux Kernel/man|7|sched}}
: [https://lore.kernel.org/lkml/?q=latency latency @ LKML]
: [https://lore.kernel.org/lkml/?q=PREEMPT_RT PREEMPT_RT @ LKML]
: [https://www.youtube.com/watch?v=O1dzeGJUvvU QA about PREEMPT_RT, LPC'23], [https://lpc.events/event/17/contributions/1483/attachments/1261/2554/state-of-the-onion.pdf State of the onion, pdf]

💾 Historical

The {{w|PREEMPT_RT}} patch has been fully merged into the mainline Linux kernel, starting from version 6.12.


{{BookCat}}</text>
      <sha1>et1b8qso6jcqjt4l73eekd6ohh9xozu</sha1>
    </revision>
  </page>
  <page>
    <title>Monopoly/Go to Jail Expansion</title>
    <ns>0</ns>
    <id>472771</id>
    <revision>
      <id>4657060</id>
      <parentid>4521497</parentid>
      <timestamp>2026-08-10T15:43:01Z</timestamp>
      <contributor>
        <username>Romaincv</username>
        <id>3619823</id>
      </contributor>
      <origin>4657060</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="6732" sha1="bd1vsr2km7dju6ljfnah0bj2g1do2jx" xml:space="preserve">The '''Go To Jail Expansion''' is one of three Monopoly expansions released by Hasbro in 2025. As its name suggests, this expansion overhauls Jail, allowing players to gain criminal missions in Jail to gain an advantage.

The object of the game has been changed - now the objective is to be the richest player once all of the properties have been purchased or one player goes bankrupt.

== Equipment ==
As an expansion, the Go to Jail Expansion does not contain the equipment of the original Monopoly. It comes with the following equipment:

* The '''Jail gameboard attachment'''. This is a piece of cardboard that is inserted into the board by the Jail space. It bears a new Corruption space (that covers the original Jail space), an area for Jail itself (which has been moved off the board but connects to the Corruption space) and an area for the new Corruption card deck.
* The '''Super Jail gameboard attachment'''. This attachment bears its own Go to Jail space (which is both aesthetically and functionally the same as the original space), an area for the new Super Jail (which connects to Go to Jail), and an area for the new Super Corruption card deck.
* Two '''Go to Jail space attachments'''. These clip onto the board and act as additional Go to Jail spaces.
* The '''Corruption''' and '''Super Corruption card decks'''. There are 32 cards in the Corruption deck and twelve in the Super Corruption deck. These allow a player to use underhanded tactics to get ahead when played.
* The '''Heist''' and '''Escape''' '''Dies'''. These are special six-sided dice that have special stickers applied to them.
* Six '''reminder cards''', and a '''guide'''.

== Setup ==
To set up the expansion, set up a normal game of Monopoly, then do the following:

* Remove the Chance and Community Chest card decks and put them back in the box. They will not be used. Place the Escape Die on the space normally occupied by the Chance cards, and the Heist Die on the space normally occupied by the Community Chest cards.
* Attach the Super Jail gameboard attachment to the board at the Go to Jail corner, so that the attachment's Go to Jail space covers the original Go to Jail space.
* Attach the Jail gameboard attachment to the board at the Jail corner, so that the Corruption space covers the original Jail space.
* Shuffle the Corruption and Super Corruption decks, then deal two Corruption cards to each player and place the remaining cards facedown on their designated areas on the attachments as draw piles.
* Attach the Go to Jail space attachments to the board, covering the tax spaces.
* Give each player a reminder card.

== Jail ==
Like with standard Monopoly, a player will be automatically sent to Jail if they land on the Go to Jail space (of which there are three with this expansion). They cannot go to Jail via a Chance or Community Chest card as they are not used with this expansion. In addition, they no longer go to Jail if they roll three consecutive doubles - instead they move again and keep rolling.

Jail itself has been moved to a special area on the attachment just off the board proper. The bail to get out of Jail has been increased to {{MonopolyCurrencySymbol}}100.

If a player is in Jail on your turn then they have two options - they may either pay the {{MonopolyCurrencySymbol}}100 bail to get out (the other two ways to get out of Jail have been removed), or stay in Jail and draw a Corruption card. Upon leaving Jail by any means, the player will reenter the board at the Corruption space and move from there.

If the player has spent three turns in Jail, then they must leave on their third turn. They pay {{MonopolyCurrencySymbol}}100 and then put their token on the Corruption space.

== Corruption Cards ==
A player draws one Corruption card each time they pass the Corruption space, get sent to Jail, or for each turn they stay in Jail.

Each Corruption cards lists an action the player may take to benefit themselves. Playing Corruption cards may only be done on a player's turn unless the card says otherwise. To play a Corruption card, the player reads its instructions out loud, then follows them and places the Corruption card at the bottom of the deck.

A Corruption card may not be played on the turn it is obtained.

Corruption cards may be involved in trades alongside other assets.

== Super Jail and Super Corruption Cards ==
Super Jail is located on the Go to Jail gameboard attachment, and like standard Jail is located just off the board proper. A player may only be sent to Super Jail if another plays plays a Corruption card that sends them there.

Whilst a player is in Super Jail they are still allowed to partake in auctions, but and sell buildings, and trade, like with regular Jail.

A player may spend up to three turns in Super Jail, and for every turn there they will draw one Super Corruption card. These have stronger benefits than standard Corruption cards but are subject to all of the same rules.

The bail to get out of Super Jail is {{MonopolyCurrencySymbol}}300. The player pays, then reenters their piece on Pacific Avenue/Regent Street, moving as normal. Alternatively, the player may get out of Super Jail by giving all of their Super Corruption cards to the player who sent them there.

If the player has spent three turns in Super Jail, then they must leave on their third turn. They pay {{MonopolyCurrencySymbol}}300 and then put their token on the Go to Jail space, ignoring its effect.

== Escape and Heist Dies ==
The Escape and Heist Dies replace the Chance and Community Chest card decks. If a player lands on a Chance or Community Chest space, then they must roll the Escape or Heist Die, respectively. There are three possible icons that can come up on either die:

* A blue background with a number in white. If this comes up, the player collects that amount of money from the Bank.
* An orange background with the Go to Jail icon. If this comes up, the player immediately goes to Jail.
* A red background with a hand giving another hand a stack of money. If this comes up, the player may draw Corruption cards equal to the number of their dice roll.

== End of the Game ==
The game will end once all of the properties have been purchased or one player goes bankrupt. Once this happens, the players collect money from the Bank for each property, equal to its purchase price as listed on its board space. They then collect rent from the Bank for each of their properties equal to its current rent value.

The players then count up their cash, and the player with the most money wins.

However, if a player's token is in Jail or Super Jail at the end of the game, that player automatically loses the game regardless of their current wealth.
{{BookCat}}</text>
      <sha1>bd1vsr2km7dju6ljfnah0bj2g1do2jx</sha1>
    </revision>
  </page>
  <page>
    <title>The Linux Kernel/Multitasking/CPU</title>
    <ns>0</ns>
    <id>475313</id>
    <revision>
      <id>4657030</id>
      <parentid>4656115</parentid>
      <timestamp>2026-08-10T12:46:47Z</timestamp>
      <contributor>
        <username>Conan</username>
        <id>3188</id>
      </contributor>
      <minor />
      <comment>*</comment>
      <origin>4657030</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="56774" sha1="3inpn5leseefzs5jg3mcjk4jfg5hqv4" xml:space="preserve">&lt;noinclude&gt;{{DISPLAYTITLE:Interrupts and CPU}}&lt;/noinclude&gt;
== Interrupts ==
An {{w|interrupt}} is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention.
An interrupt alerts the processor to a high-priority condition requiring the interruption of the current code the processor is executing.
The processor responds by suspending its current activities, saving its state, and executing a function called an ''interrupt handler'' (or an interrupt service routine, ISR) to deal with the event.
This interruption is temporary, and, after the interrupt handler finishes, the processor resumes normal activities.

There are two types of interrupts: hardware interrupts and software interrupts.
Hardware interrupts are used by devices to communicate that they require attention from the operating system.
For example, pressing a key on the keyboard or moving the mouse triggers hardware interrupts that cause the processor to read the keystroke or mouse position.
Unlike the software type, hardware interrupts are asynchronous and can occur in the middle of instruction execution, requiring additional care in programming.
The act of initiating a hardware interrupt is referred to as an ''interrupt request'' - IRQ ↪ {{w|Interrupt descriptor table|IDT}} ↪ {{The Linux Kernel/id|common_interrupt}} on x86.

A software interrupt is caused either by an exceptional condition in the processor itself, or a special instruction in the instruction set which causes an interrupt when it is executed.
The former is often called a ''{{w|Trap (computing)|trap}}'' (⚙️ {{The Linux Kernel/id|do_trap}}) or ''exception'' and is used for errors or events occurring during program execution that are exceptional enough that they cannot be handled within the program itself.
For example, if the processor's arithmetic logic unit is commanded to divide a number by zero, this impossible demand will cause a ''divide-by-zero exception'' (⚙️ {{The Linux Kernel/id|X86_TRAP_DE}}), perhaps causing the computer to abandon the calculation or display an error message.
Software interrupt instructions function similarly to subroutine calls and are used for a variety of purposes, such as to request services from low-level system software such as device drivers.
For example, computers often use software interrupt instructions to communicate with the disk controller to request data be read or written to the disk.

Each interrupt has its own interrupt handler.  The number of hardware interrupts is limited by the number of interrupt request (IRQ) lines to the processor, but there may be hundreds of different software interrupts.


⚲ API

: /proc/interrupts
: {{The Linux Kernel/man|1|irqtop}} &amp;ndash; utility to display kernel interrupt information
: [https://github.com/Irqbalance/irqbalance irqbalance] &amp;ndash; distribute hardware interrupts across processors on a multiprocessor system
: There are many ways to request ISR, two of them
: {{The Linux Kernel/id|devm_request_threaded_irq}} &amp;ndash; preferable, managed device with threaded ISR
: {{The Linux Kernel/id|devm_request_irq}} &amp;ndash; managed version
:: {{The Linux Kernel/id|request_irq}}
::: {{The Linux Kernel/id|request_threaded_irq}}
: {{The Linux Kernel/id|free_irq}}
: {{The Linux Kernel/include|linux/interrupt.h}} &amp;ndash; main interrupt support header
:: {{The Linux Kernel/id|irqaction}} &amp;ndash; contains handler functions 
: {{The Linux Kernel/include|linux/irq.h}}
:: {{The Linux Kernel/id|irq_data}}
: {{The Linux Kernel/include|linux/irqflags.h}}
:: {{The Linux Kernel/id|irqs_disabled}}
:: {{The Linux Kernel/id|local_irq_save}} ...
:: {{The Linux Kernel/id|local_irq_disable}} ...
: {{The Linux Kernel/include|linux/irqdesc.h}}
:: {{The Linux Kernel/id|irq_desc}}
: {{The Linux Kernel/include|linux/irqdomain.h}}
:: {{The Linux Kernel/id|irq_domain}} &amp;ndash; hardware interrupt number translation object
:: {{The Linux Kernel/id|irq_domain_get_irq_data}}
: {{The Linux Kernel/include|linux/msi.h}} &amp;ndash; {{w|Message Signaled Interrupts}}
:: {{The Linux Kernel/id|msi_desc}}
: Structure of structures:
:: {{The Linux Kernel/id|irq_desc}} is container of
::: {{The Linux Kernel/id|irq_data}}
:::: irq &amp;ndash; interrupt number
::: {{The Linux Kernel/id|irq_common_data}}
::: list of {{The Linux Kernel/id|irqaction}}


⚙️ Internals

: {{The Linux Kernel/source|kernel/irq/settings.h}} &amp;ndash; IRQ descriptor status flags
: {{The Linux Kernel/source|kernel/irq}} &amp;ndash; generic IRQ handling
:: {{The Linux Kernel/source|kernel/irq/internals.h}} &amp;ndash; IRQ subsystem internal functions
: ls /sys/kernel/debug/irq/domains/
:: {{The Linux Kernel/id|x86_vector_domain}}, {{The Linux Kernel/id|x86_vector_domain_ops}}
: {{The Linux Kernel/id|irq_chip}}
: {{The Linux Kernel/id|load_idt}} &amp;ndash; load Interrupt Descriptor Table
: {{The Linux Kernel/source|arch/x86/include/asm/idtentry.h}} &amp;ndash; interrupt entry/exit definitions
: {{The Linux Kernel/source|arch/x86/include/asm/hw_irq.h}} &amp;ndash; x86 hardware IRQ definitions
:: {{The Linux Kernel/id|irq_entries_start}} &amp;ndash; hardware IRQ entry stubs
: {{The Linux Kernel/source|arch/x86/kernel/irq.c}} &amp;ndash; x86 interrupt handling
:: {{The Linux Kernel/id|common_interrupt}} &amp;ndash; handles all normal device IRQs on x86
: {{The Linux Kernel/source|arch/x86/kernel/apic}} &amp;ndash; {{w|Advanced Programmable Interrupt Controller|APIC}}
:: {{The Linux Kernel/source|arch/x86/kernel/apic/apic.c}} &amp;ndash; local APIC core (timer, calibration, spurious interrupt)
:: {{The Linux Kernel/source|arch/x86/kernel/apic/io_apic.c}} &amp;ndash; {{w|IOAPIC|I/O APIC}}, routes device IRQs to CPUs
:: {{The Linux Kernel/source|arch/x86/kernel/apic/x2apic_cluster.c}} &amp;ndash; {{w|x2APIC}} (&gt;256 CPUs)
:: {{The Linux Kernel/source|arch/x86/kernel/apic/ipi.c}} &amp;ndash; {{w|Inter-processor interrupt|IPI}}, see [[#IPI|IPI]]
:: {{The Linux Kernel/source|arch/x86/kernel/apic/hw_nmi.c}} &amp;ndash; hardware NMI watchdog via APIC
:: {{The Linux Kernel/source|arch/x86/kernel/apic/vector.c}} &amp;ndash; IRQ vector allocation
:: {{The Linux Kernel/source|arch/x86/kernel/apic/msi.c}} &amp;ndash; {{w|Message Signaled Interrupts|MSI}} via APIC

📖 References
: {{The Linux Kernel/doc|IRQs|core-api/irq}}
:: {{The Linux Kernel/doc|The irq_domain interrupt number mapping library|core-api/irq/irq-domain.html}}
: {{The Linux Kernel/doc|Linux generic IRQ handling|core-api/genericirq.html}}
: {{The Linux Kernel/doc|Message Signaled Interrupts: The MSI Driver Guide|PCI/msi-howto.html}}
: {{The Linux Kernel/doc|Lock types and their rules|locking/locktypes.html}}
: {{The Linux Kernel/doc|Hard IRQ Context|kernel-hacking/locking.html#hard-irq-context}}
: [https://0xax.gitbooks.io/linux-insides/content/Interrupts/ Interrupts]


👁 Examples
: {{The Linux Kernel/id|dummy_irq_chip}} &amp;ndash; dummy interrupt chip implementation
: {{The Linux Kernel/source|lib/locking-selftest.c}} &amp;ndash; locking correctness self-tests


=== IRQ affinity ===

⚲ API
: /proc/irq/default_smp_affinity
: /proc/irq/*/smp_affinity and /proc/irq/*/smp_affinity_list


Common types and functions:
: struct {{The Linux Kernel/id|irq_affinity}} &amp;ndash; description for automatic irq affinity assignments, see {{The Linux Kernel/id|devm_platform_get_irqs_affinity}}
: struct {{The Linux Kernel/id|irq_affinity_desc}} &amp;ndash; interrupt affinity descriptor, see {{The Linux Kernel/id|irq_update_affinity_desc}}, {{The Linux Kernel/id|irq_create_affinity_masks}}
: {{The Linux Kernel/id|irq_set_affinity}}
: {{The Linux Kernel/id|irq_get_affinity_mask}} 
: {{The Linux Kernel/id|irq_can_set_affinity}}
: {{The Linux Kernel/id|irq_set_affinity_hint}} 
: {{The Linux Kernel/id|irqd_affinity_is_managed}} 
: {{The Linux Kernel/id|irq_data_get_affinity_mask}}
: {{The Linux Kernel/id|irq_data_get_effective_affinity_mask}} 
: {{The Linux Kernel/id|irq_data_update_effective_affinity}} 
: {{The Linux Kernel/id|irq_set_affinity_notifier}} 
: {{The Linux Kernel/id|irq_affinity_notify}} 
: {{The Linux Kernel/id|irq_chip_set_affinity_parent}} 
: {{The Linux Kernel/id|irq_set_vcpu_affinity}}


🛠️ Utilities
: [https://man.archlinux.org/man/extra/irqbalance/irqbalance.1.en irqbalance] – distributes hardware interrupts across CPUs


📖 References
: {{The Linux Kernel/doc|SMP IRQ affinity|core-api/irq/irq-affinity.html}}
: [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cpu-partitioning/start#irq_affinity IRQ affinity, LF]
: [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=managed_irq managed_irq kernel parameter], [https://lore.kernel.org/lkml/?q=managed_irq @LKML]
: [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=irqaffinity= irqaffinity kernel parameter], [https://lore.kernel.org/lkml/?q=irqaffinity @LKML]


=== Non-maskable interrupts ===

⚲ API
: {{The Linux Kernel/include|linux/nmi.h}}
:: {{The Linux Kernel/id|in_nmi}}
:: {{The Linux Kernel/id|touch_nmi_watchdog}}
:: ...
: {{The Linux Kernel/include|trace/events/nmi.h}}
: {{The Linux Kernel/source|arch/x86/include/asm/nmi.h}} &amp;ndash; x86 NMI handler registration
:: {{The Linux Kernel/id|register_nmi_handler}}
:: {{The Linux Kernel/id|unregister_nmi_handler}}


⚙️ Internals
: {{The Linux Kernel/source|arch/x86/kernel/nmi.c}} &amp;ndash; x86 NMI handler
: {{The Linux Kernel/source|arch/x86/kernel/apic/hw_nmi.c}} &amp;ndash; hardware NMI watchdog via APIC
: {{The Linux Kernel/source|arch/x86/kernel/nmi_selftest.c}} &amp;ndash; NMI IPI self-tests


📖 References
: {{The Linux Kernel/doc|NMI Trace Events|trace/events-nmi.html}}


📚 Further reading
: [https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-6.html Non-maskable interrupt handler] (NMI)


=== ... ===

📚 Further reading about interrupts
: IDT &amp;ndash; {{w|Interrupt descriptor table}}
: [https://www.felixcloutier.com/x86/lgdt:lidt LGDT/LIDT &amp;ndash; Load Global/Interrupt Descriptor Table Register] asm instruction

== Deferred works ==

=== Scheduler context ===

==== kthread work ====

This framework simplifies the use of kernel kthreads.
A {{The Linux Kernel/id|kthread_work}} item can be queued with {{The Linux Kernel/id|kthread_queue_work}} and flushed using {{The Linux Kernel/id|kthread_flush_work}}.
All queued kthread_work items are processed by a dedicated kernel thread executing the {{The Linux Kernel/id|kthread_worker_fn}} function.

⚲ API
: {{The Linux Kernel/id|kthread_work}} &amp;ndash; contains {{The Linux Kernel/id|kthread_work_func_t}} to execute
:: {{The Linux Kernel/id|kthread_init_work}}
:: {{The Linux Kernel/id|kthread_flush_work}}
: {{The Linux Kernel/id|kthread_worker}} &amp;ndash; links a kthread_work and a task
:: {{The Linux Kernel/id|kthread_run_worker}} &amp;ndash; creates and wakes a kthread worker
::: {{The Linux Kernel/id|kthread_create_worker}}
::: {{The Linux Kernel/id|kthread_flush_worker}}
:: {{The Linux Kernel/id|kthread_destroy_worker}}
: {{The Linux Kernel/id|kthread_queue_work}} &amp;ndash; queues a kthread_work on a kthread_worker


⚙️ Internals
: {{The Linux Kernel/id|__kthread_create_worker_on_node}}
: {{The Linux Kernel/id|kthread_worker_fn}} &amp;ndash; executes work's function


👁 Example usages
: {{The Linux Kernel/id|watchdog_kworker}}, {{The Linux Kernel/id|pwq_release_worker}}, {{The Linux Kernel/id|pump_messages}}

==== Threaded IRQ ====

⚲ API
{{The Linux Kernel/id|devm_request_threaded_irq}}, {{The Linux Kernel/id|request_threaded_irq}}
ISR should return IRQ_WAKE_THREAD to run thread function

⚙️ Internals
: {{The Linux Kernel/id|setup_irq_thread}}, {{The Linux Kernel/id|irq_thread}}
: {{The Linux Kernel/source|kernel/irq/manage.c}} &amp;ndash; IRQ request, free and affinity management

📖 References
: {{The Linux Kernel/doc|request_threaded_irq|core-api/genericirq.html#c.request_threaded_irq}}


==== Work and workqueue ====

Generic async execution with shared worker pool.

⚲ API
: {{The Linux Kernel/id|PF_WQ_WORKER}} &amp;ndash; workqueue worker process flag
: {{The Linux Kernel/include|linux/workqueue.h}}, {{The Linux Kernel/include|linux/workqueue_types.h}}
: {{The Linux Kernel/id|work_struct}}, {{The Linux Kernel/id|INIT_WORK}}
: {{The Linux Kernel/id|delayed_work}}, {{The Linux Kernel/id|INIT_DELAYED_WORK}}, {{The Linux Kernel/id|cancel_delayed_work_sync}}
: {{The Linux Kernel/id|workqueue_struct}}
:: {{The Linux Kernel/id|devm_alloc_workqueue}}
::: {{The Linux Kernel/id|alloc_workqueue}}
:: {{The Linux Kernel/id|destroy_workqueue}}
: {{The Linux Kernel/id|schedule_work}} &amp;ndash; queues work on the system workqueue ↯
:: {{The Linux Kernel/id|queue_work}} &amp;ndash; queues work on a workqueue
::: {{The Linux Kernel/id|queue_work_on}} &amp;ndash; on a specific CPU
: {{The Linux Kernel/id|show_all_workqueues}}
:: {{The Linux Kernel/id|show_one_workqueue}}
: {{The Linux Kernel/id|system_power_efficient_wq}} ...


👁 Example usage {{The Linux Kernel/source|samples/ftrace/sample-trace-array.c}}


⚙️ Internals
: {{The Linux Kernel/source|kernel/workqueue.c}} &amp;ndash; generic async execution with shared worker pool
:: {{The Linux Kernel/id|workqueue_init}}
::: {{The Linux Kernel/id|create_worker}}
:::: {{The Linux Kernel/id|worker_thread}}
::::: {{The Linux Kernel/id|process_one_work}}
:: {{The Linux Kernel/id|format_worker_id}} &amp;ndash; names kworker kthreads
:: {{The Linux Kernel/id|pool_workqueue}}
::: {{The Linux Kernel/id|worker_pool}}


📖 References
: {{The Linux Kernel/doc|Concurrency Managed Workqueue|core-api/workqueue.html}}
: [https://sysprog21.github.io/lkmpg/#work-queues LKMPG: Work queues]

=== Interrupt context ===

: {{The Linux Kernel/include|linux/irq_work.h}} &amp;ndash; run callbacks from hardirq or NMI context where normal work queues can't be used
:: {{The Linux Kernel/id|irq_work_queue}} &amp;ndash; enqueue work on the current CPU, triggers {{The Linux Kernel/id|IRQ_WORK_VECTOR}} IPI if needed
:: {{The Linux Kernel/id|irq_work_sync}} &amp;ndash; wait for completion
:: {{The Linux Kernel/source|kernel/irq_work.c}} &amp;ndash; irq_work implementation
:: 👁 {{The Linux Kernel/source|samples/trace_printk/trace-printk.c}}

==== Timers ====

⚠️ Not to be confused with
[[The_Linux_Kernel/Multitasking#POSIX_Timers|POSIX timer]] – userspace API,
[[The_Linux_Kernel/Debugging#Watchdogs|watchdog timer]] – hang detection,
[[#Clock_infrastructure|local APIC timer]] – per-CPU hardware, drives the tick.

===== softirq timer =====

This timer is a softirq for periodical tasks with jiffies resolution

⚲ API
: {{The Linux Kernel/include|linux/timer.h}}
: {{The Linux Kernel/id|timer_list}}, {{The Linux Kernel/id|DEFINE_TIMER}}, {{The Linux Kernel/id|timer_setup}}
: {{The Linux Kernel/id|mod_timer}} &amp;mdash; sets expiration time in jiffies. 
: {{The Linux Kernel/id|del_timer}}


⚙️ Internals
: {{The Linux Kernel/source|kernel/time/timer.c}} &amp;ndash; kernel internal timers
:: {{The Linux Kernel/id|timer_bases}}


👁 Examples
: {{The Linux Kernel/id|input_enable_softrepeat}} and {{The Linux Kernel/id|input_start_autorepeat}}


📚 References
: {{The Linux Kernel/doc|Time and timer routines|driver-api/basics.html#time-and-timer-routines}}
:: {{The Linux Kernel/doc|mod_timer_pending ... |driver-api/basics.html#c.mod_timer_pending}}

===== High-resolution timer =====

⚲ API
: /proc/timer_list
: /proc/sys/kernel/timer_migration
: {{The Linux Kernel/include|linux/hrtimer_defs.h}}
: {{The Linux Kernel/include|linux/hrtimer.h}}
: {{The Linux Kernel/id|hrtimer}}, hrtimer.function &amp;mdash; callback
: {{The Linux Kernel/id|hrtimer_init}}
: {{The Linux Kernel/id|hrtimer_setup}}
: {{The Linux Kernel/id|hrtimer_start}} &amp;mdash; starts a timer with nanosecond resolution 
: {{The Linux Kernel/id|hrtimer_cancel}}


👁 Examples {{The Linux Kernel/id|alarm_init}}, {{The Linux Kernel/id|watchdog_enable}}


⚙️ Internals
: {{The Linux Kernel/id|CONFIG_HIGH_RES_TIMERS}}
: {{The Linux Kernel/source|kernel/time/tick-internal.h}} &amp;ndash; tick and timer internal definitions
:: {{The Linux Kernel/id|hrtimer_bases}}
: {{The Linux Kernel/source|kernel/time/hrtimer.c}} &amp;ndash; high-resolution timer implementation
: {{The Linux Kernel/source|kernel/time/itimer.c}} &amp;ndash; interval timers
: {{The Linux Kernel/source|kernel/time/timer_list.c}} &amp;ndash; /proc/timer_list debugfs


📚 HR timers references
: {{The Linux Kernel/doc|High-resolution timers|driver-api/basics.html#high-resolution-timers}}
: {{The Linux Kernel/doc|hrtimers - subsystem for high-resolution kernel timers|timers/hrtimers.html}}
: {{The Linux Kernel/doc|high resolution timers and dynamic ticks design notes|timers/highres.html}}

===== Tick and NO_HZ =====

The tick is the periodic timer interrupt that drives scheduling, timekeeping, and RCU.
The NO_HZ subsystem reduces or eliminates tick interrupts to save power and reduce latency.

⚲ API
: /sys/devices/system/cpu/nohz_full – active nohz_full CPUs
: [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=nohz_full= nohz_full=] boot parameter – list of CPUs to run tickless
: {{The Linux Kernel/include|linux/tick.h}} – tick control API
:: {{The Linux Kernel/id|tick_nohz_full_running}} – true if any CPU runs tickless

🪛 Compile-time configurations ({{The Linux Kernel/source|kernel/time/Kconfig}})
: {{The Linux Kernel/id|CONFIG_HZ_PERIODIC}} – constant-rate tick, always firing
: {{The Linux Kernel/id|CONFIG_NO_HZ_IDLE}} – stop tick when CPU is idle (default on most distros)
: {{The Linux Kernel/id|CONFIG_NO_HZ_FULL}} – stop tick even when running a single task, for RT and latency-sensitive workloads, see [[#CPU_isolation|CPU isolation]]

⚙️ Internals
: {{The Linux Kernel/source|kernel/time/tick-common.c}} – periodic tick setup
: {{The Linux Kernel/source|kernel/time/tick-oneshot.c}} – oneshot mode for hrtimers and NO_HZ
: {{The Linux Kernel/source|kernel/time/tick-sched.c}} – NO_HZ tick scheduling logic
: {{The Linux Kernel/source|kernel/time/tick-broadcast.c}} – broadcast tick for CPUs in deep idle where local timer stops ([[#Idle|C3+]])
: {{The Linux Kernel/source|kernel/time/timer_migration.c}} – migrate timers from idle to busy CPUs

📖 References
: {{The Linux Kernel/doc|NO_HZ: Reducing Scheduling-Clock Ticks|timers/no_hz.html}}
: [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/ticklesskernel Tickless kernel, RT wiki]
: {{The Linux Kernel/doc|high resolution timers and dynamic ticks design notes|timers/highres.html}}

===== Clock infrastructure =====

⚠️ Not to be confused with
[[The_Linux_Kernel/System#Hardware_Device_Drivers|drivers/clk framework]] – SoC {{w|Clock signal|clock}} tree management.

Clocksources read current time (passive counters).
Clock event devices fire interrupts at a programmed time (active).
Together they are the foundation for timekeeping, timers, tick, and NO_HZ.


⚲ Clocksources – &quot;what time is it?&quot;
: /sys/devices/system/clocksource/clocksource0/current_clocksource
: /sys/devices/system/clocksource/clocksource0/available_clocksource
:: {{w|Time Stamp Counter|TSC}} – fastest, per-CPU, x86
:: {{w|High Precision Event Timer|HPET}} – system-wide, MMIO
:: ACPI PM timer – never stops in any C-state, slow
: {{The Linux Kernel/include|linux/clocksource.h}} – {{The Linux Kernel/id|clocksource}}, {{The Linux Kernel/id|clocksource_register_hz}}


⚲ Clock event devices – &quot;wake me at time X&quot;
: {{The Linux Kernel/include|linux/clockchips.h}} – {{The Linux Kernel/id|clock_event_device}}, {{The Linux Kernel/id|clockevents_config_and_register}}
: Local {{w|Advanced Programmable Interrupt Controller|APIC}} timer – per-CPU, fastest, stops in [[#Idle|C3+]], {{The Linux Kernel/id|local_apic_timer_interrupt}}
: {{w|High Precision Event Timer|HPET}} – system-wide, used as broadcast fallback
&lt;!-- PIT (i8254) – legacy, stopped at boot on modern hardware --&gt;


⚙️ Internals
: {{The Linux Kernel/source|kernel/time/clocksource.c}} – clocksource selection and watchdog
: {{The Linux Kernel/source|kernel/time/clockevents.c}} – clock event device framework
: {{The Linux Kernel/source|kernel/time/jiffies.c}} – jiffies clocksource (fallback)


===== ... =====

📖 Timers references
: {{The Linux Kernel/doc|Timers|timers}}
: [https://lwn.net/Articles/913568/ Better CPU selection for timer expiration]

==== Tasklet ====

tasklet is a softirq, for time critical operations

⚲ API is deprecated in favor of threaded IRQs: {{The Linux Kernel/id|devm_request_threaded_irq}}
: {{The Linux Kernel/id|tasklet_struct}}, {{The Linux Kernel/id|tasklet_init}}, {{The Linux Kernel/id|tasklet_schedule}}


⚙️ Internals: {{The Linux Kernel/id|tasklet_action_common}} HI_SOFTIRQ, TASKLET_SOFTIRQ


==== Softirq ====

softirq is internal system facility and should not be used directly.
Use tasklet or threaded IRQs

⚲ API
: {{The Linux Kernel/include|linux/interrupt.h}}
: cat /proc/softirqs
: {{The Linux Kernel/id|open_softirq}} registers {{The Linux Kernel/id|softirq_action}}
: {{The Linux Kernel/id|raise_softirq}}
: {{The Linux Kernel/id|tasklet_schedule}}
:: {{The Linux Kernel/id|__tasklet_schedule}}


⚙️ Internals
: {{The Linux Kernel/source|kernel/softirq.c}} &amp;ndash; software interrupt handling
:: {{The Linux Kernel/id|__do_softirq}} &amp;ndash; main softirq processing loop


📖 References
: [https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-9.html Introduction to deferred interrupts (Softirq, Tasklets and Workqueues)]
: [https://0xax.gitbooks.io/linux-insides/content/Timers/ Timers and time management]
: [https://linux-kernel-labs.github.io/refs/heads/master/labs/deferred_work.html Deferred work, linux-kernel-labs]
: [https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch07.html Chapter 7. Time, Delays, and Deferred Work]

==CPU specific==


🖱️ GUI
: [https://manpages.ubuntu.com/manpages/kinetic/en/man8/tuna.8.html tuna] &amp;ndash; program for tuning running processes


⚲ API
: cat /proc/cpuinfo
: /sys/devices/system/cpu/
: /sys/devices/system/node/
: /sys/cpu/
: /sys/fs/cgroup/cpu/
: grep -i cpu /proc/self/status
: [https://manpages.ubuntu.com/manpages/jammy/man1/rdmsr.1.html rdmsr] &amp;ndash; tool for reading CPU machine specific registers (MSR)
: {{The Linux Kernel/man|1|lscpu}} &amp;ndash; display information about the CPU architecture

: {{The Linux Kernel/include|linux/arch_topology.h}} &amp;ndash; arch specific cpu topology information 
: {{The Linux Kernel/include|linux/cpu.h}} &amp;ndash; generic cpu definition 
: {{The Linux Kernel/include|linux/cpu_cooling.h}} 
: {{The Linux Kernel/include|linux/cpu_pm.h}} 
: {{The Linux Kernel/include|linux/cpufeature.h}}
: {{The Linux Kernel/source|arch/x86/include/asm/cpufeature.h}} &amp;ndash; x86 CPU feature detection
: {{The Linux Kernel/include|linux/peci-cpu.h}} 
: {{The Linux Kernel/include|linux/sched/cputime.h}} &amp;ndash; cputime accounting APIs
: {{The Linux Kernel/include|linux/clk.h}} &amp;ndash; interfaces for managing hardware clocks in device drivers


⚙️ Internals

: {{The Linux Kernel/source|drivers/base/cpu.c}} &amp;ndash; CPU driver model subsystem
:: {{The Linux Kernel/id|cpu_dev_init}}


=== Cache ===

: {{The Linux Kernel/include|linux/cacheflush.h}}
:: {{The Linux Kernel/source|arch/x86/include/asm/cacheflush.h}}: {{The Linux Kernel/id|clflush_cache_range}}
: {{The Linux Kernel/include|linux/cache.h}} &amp;ndash; cache line alignment macros
:: {{The Linux Kernel/id|____cacheline_aligned}} &amp;ndash; align to cache line boundary to avoid false sharing
:: {{The Linux Kernel/id|__cacheline_aligned}} &amp;ndash; same, plus place in .data..cacheline_aligned section
:: {{The Linux Kernel/id|____cacheline_aligned_in_smp}} &amp;ndash; same, but no-op on uniprocessor builds
:: {{The Linux Kernel/id|__read_mostly}} &amp;ndash; place in a cache-friendly section for rarely written data
:: {{The Linux Kernel/id|__ro_after_init}} &amp;ndash; writable during init, read-only after boot (security hardening)
:: {{The Linux Kernel/id|DEFINE_PER_CPU_CACHE_HOT}} &amp;ndash; per-CPU variable in .data..hot section, used for {{The Linux Kernel/id|current_task}}, {{The Linux Kernel/id|__preempt_count}}
:: {{The Linux Kernel/id|L1_CACHE_BYTES}}, {{The Linux Kernel/id|SMP_CACHE_BYTES}} &amp;ndash; 64 bytes typically
:: {{The Linux Kernel/source|arch/x86/include/asm/cache.h}} &amp;ndash; x86 cache line size definitions

🔨 [https://manpages.ubuntu.com/manpages/resolute/man1/stress-ng.1.html#:~:text=%2D%2Dcache stress-ng --cache]

⚙️ Internals

: {{The Linux Kernel/source|arch/x86/mm/pat/set_memory.c}} &amp;ndash; page attribute table memory type control
: {{The Linux Kernel/source|arch/x86/kernel/cpu/mtrr/}} &amp;ndash; memory type range register driver

📚 Further reading
: MTRR &amp;ndash; {{w|Memory type range register}}
: {{w|CPU cache}}

=== {{w|Symmetric_multiprocessing|SMP}} ===

This chapter is about multiprocessing and {{w|Multi-core processor|multi-core}} aspects of Linux kernel.

Key concepts and features of Linux SMP include:
* Symmetry: In an SMP system, all processors are considered the same without hardware hierarchy in contradiction to use of {{w|coprocessor}}s.
* Load balancing: The Linux kernel employs load balancing mechanisms to distribute tasks evenly among available CPU cores. This prevents any one core from becoming overwhelmed while others remain underutilized.
* Parallelism: SMP enables parallel processing, where multiple threads or processes can execute simultaneously on different CPU cores. This can significantly improve the execution speed of applications that are designed to take advantage of multiple threads.
* Thread scheduling: The Linux kernel scheduler is responsible for determining which threads or processes run on which CPU cores and for how long. It aims to optimize performance by minimizing contention and maximizing CPU utilization.
* Shared memory: In an SMP system, all CPU cores typically share the same physical memory space. This allows processes and threads running on different cores to communicate and share data more efficiently.
* NUMA &amp;ndash; {{w|Non-Uniform Memory Access}}: In larger SMP systems, memory access times might not be uniform due to the physical arrangement of memory banks and processors. Linux has mechanisms to handle NUMA architectures efficiently, allowing processes to be scheduled on CPUs closer to their associated memory.
* Cache coherency: SMP systems require mechanisms to ensure that all CPU cores have consistent views of memory. Cache coherency protocols ensure that changes made to shared memory locations are correctly propagated to all cores.
* Scalability: SMP systems can be scaled up to include more CPU cores, enhancing the overall computing power of the system. However, as the number of cores increases, challenges related to memory access, contention, and communication between cores may arise.
* Kernel and user space: Linux applications running in user space can take advantage of SMP without needing to be aware of the underlying hardware details. The kernel handles the management of CPU cores and resource allocation.


⚲ API
: &lt;code&gt;ps -PLe&lt;/code&gt; &amp;ndash; lists threads with processor that the thread last executed on (the third column PSR).
: {{The Linux Kernel/man|2|getcpu}} &amp;ndash; determine CPU and NUMA node on which the calling thread is running
: {{The Linux Kernel/man|8|chcpu}} &amp;ndash; configure CPUs
: {{The Linux Kernel/man|3|CPU_SET}} &amp;ndash; macros for manipulating CPU sets
: {{The Linux Kernel/include|linux/smp.h}}
:: The most commonly used functions:
:: {{The Linux Kernel/id|crash_smp_send_stop}} – halts all CPUs except the calling one in a crash context
:: {{The Linux Kernel/id|get_cpu}} – disables preemption and returns the current processor ID
:: {{The Linux Kernel/id|panic_smp_self_stop}} – stops the local CPU during a panic while ensuring others halt
:: {{The Linux Kernel/id|put_cpu}} – re-enables preemption after a previous get_cpu call
:: {{The Linux Kernel/id|raw_smp_processor_id}} – returns the current CPU ID without preemption safety
:: {{The Linux Kernel/id|setup_max_cpus}} – sets up the maximum number of CPUs to be brought online
:: {{The Linux Kernel/id|smp_init}} – initializes core SMP structures and state during boot
:: {{The Linux Kernel/id|smp_prepare_boot_cpu}} – prepares the boot CPU during early SMP initialization
:: {{The Linux Kernel/id|smp_prepare_cpus}} – prepares all CPUs for booting before secondary CPUs are started
:: {{The Linux Kernel/id|smp_processor_id}} – returns the ID of the current CPU with preemption checks
:: {{The Linux Kernel/id|smp_send_stop}} – stops all other CPUs in response to critical events
:: {{The Linux Kernel/id|wake_up_all_idle_cpus}} – wakes all idle CPUs to ensure prompt task execution
: {{The Linux Kernel/include|linux/cpu.h}}
: {{The Linux Kernel/include|linux/group_cpus.h}}: {{The Linux Kernel/id|group_cpus_evenly}} &amp;ndash; groups all CPUs evenly per NUMA/CPU locality
: {{The Linux Kernel/include|asm-generic/percpu.h}}
: {{The Linux Kernel/include|linux/percpu-defs.h}} &amp;ndash; basic definitions for percpu areas
:: {{The Linux Kernel/id|this_cpu_ptr}}
: {{The Linux Kernel/include|linux/percpu.h}} 
: {{The Linux Kernel/include|linux/percpu-refcount.h}} 
: {{The Linux Kernel/include|linux/percpu-rwsem.h}}
: {{The Linux Kernel/include|linux/preempt.h}}
:: {{The Linux Kernel/id|migrate_disable}}, {{The Linux Kernel/id|migrate_enable}}
: /sys/bus/cpu
: [[#per_CPU_local_lock|per CPU local_lock]]
: {{The Linux Kernel/include|linux/topology.h}} &amp;ndash; {{The Linux Kernel/id|cpu_to_node}}, {{The Linux Kernel/id|numa_node_id}}
: {{The Linux Kernel/source|arch/x86/include/asm/topology.h}} &amp;ndash; x86 NUMA and CPU topology
: See also [[../../Memory#NUMA|NUMA memory section]]


⚙️ Internals
: {{The Linux Kernel/id|boot_cpu_init}} activates the first CPU
: {{The Linux Kernel/id|smp_prepare_cpus}} initializes rest CPUs during boot
: {{The Linux Kernel/id|cpu_number}}
: {{The Linux Kernel/id|CONFIG_SMP}}
:: {{The Linux Kernel/id|CONFIG_NUMA}}
: {{The Linux Kernel/include|trace/events/percpu.h}}
: {{The Linux Kernel/file|drivers/base/cpu.c}} &amp;ndash; CPU driver model subsystem support
: {{The Linux Kernel/file|kernel/cpu.c}} &amp;ndash; CPU hotplug state machine
: smpboot
:: {{The Linux Kernel/include|linux/smpboot.h}}
:: {{The Linux Kernel/source|kernel/smpboot.c}} &amp;ndash; common SMP CPU bringup/teardown
:: {{The Linux Kernel/source|arch/x86/kernel/smpboot.c}} &amp;ndash; x86 SMP booting
: {{The Linux Kernel/source|lib/group_cpus.c}} &amp;ndash; distribute CPUs evenly across groups


🛠️ Utilities
: [https://man.archlinux.org/man/extra/irqbalance/irqbalance.1.en irqbalance] – distributes hardware interrupts across CPUs
: {{The Linux Kernel/man|8|numactl}} &amp;ndash; controls NUMA policy for processes or shared memory


📖 References
: {{The Linux Kernel/doc|Per-CPU Data|kernel-hacking/locking.html#per-cpu-data}}
: {{The Linux Kernel/doc|How CPU topology info is exported via sysfs|admin-guide/cputopology.html}}


📚 Further reading
: [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/customizing-tuned-profiles_monitoring-and-managing-system-status-and-performance#functionalities-of-the-scheduler-tuned-plug-in_customizing-tuned-profiles Functionalities of the scheduler TuneD plugin]
: [https://man.archlinux.org/man/tuned-adm.8 tuned-adm] &amp;ndash; command line tool for switching between different tuning profiles


==== {{w|Inter-processor interrupt|IPI}} ====

An inter-processor interrupt is a signal sent from one CPU to another to request an action such as rescheduling, TLB flush, or function execution.

⚲ API
: {{The Linux Kernel/id|smp_send_reschedule}} &amp;ndash; sends a reschedule IPI to a target CPU
: {{The Linux Kernel/id|smp_call_function}} &amp;ndash; invokes a function on all other CPUs via IPI
:: {{The Linux Kernel/id|smp_call_function_many}} &amp;ndash; on a specified set of CPUs
: {{The Linux Kernel/id|smp_call_function_single}} &amp;ndash; on a single target CPU
:: {{The Linux Kernel/id|smp_call_function_single_async}} &amp;ndash; asynchronous variant
: {{The Linux Kernel/id|smp_call_on_cpu}} &amp;ndash; execute on a specific CPU and wait for result
: {{The Linux Kernel/id|on_each_cpu}} &amp;ndash; run a function on all CPUs
:: {{The Linux Kernel/id|on_each_cpu_mask}} &amp;ndash; on a specified set of CPUs
:: {{The Linux Kernel/id|on_each_cpu_cond_mask}} &amp;ndash; conditionally on selected CPUs
: {{The Linux Kernel/id|smp_call_func_t}} &amp;ndash; callback typedef

⚙️ Internals
: {{The Linux Kernel/include|trace/events/ipi.h}}
: {{The Linux Kernel/file|kernel/irq/ipi.c}} &amp;ndash; generic IPI helpers
:: {{The Linux Kernel/id|ipi_send_single}}, {{The Linux Kernel/id|ipi_send_mask}}
: {{The Linux Kernel/source|arch/x86/kernel/apic/ipi.c}} &amp;ndash; x86 IPI via APIC
: {{The Linux Kernel/source|arch/x86/include/asm/irq_vectors.h}} &amp;ndash; x86 IPI vector types:
:: {{The Linux Kernel/id|RESCHEDULE_VECTOR}} &amp;ndash; used by {{The Linux Kernel/id|smp_send_reschedule}}
:: {{The Linux Kernel/id|CALL_FUNCTION_VECTOR}} &amp;ndash; used by {{The Linux Kernel/id|smp_call_function_many}}
:: {{The Linux Kernel/id|CALL_FUNCTION_SINGLE_VECTOR}} &amp;ndash; used by {{The Linux Kernel/id|smp_call_function_single}}
:: {{The Linux Kernel/id|IRQ_WORK_VECTOR}} &amp;ndash; used by {{The Linux Kernel/id|irq_work_queue}}, see [[#Interrupt_context|Interrupt context]]
:: {{The Linux Kernel/id|NMI_VECTOR}} &amp;ndash; used by watchdog, {{The Linux Kernel/id|crash_smp_send_stop}}

==== CPU affinity ====

Affinity refers to assigning a process or thread to specific CPU cores.
This helps control which CPUs execute tasks, potentially improving performance by reducing data movement between cores.
It can be managed using system calls or commands.
Affinity can be represented as CPU bitmask: {{The Linux Kernel/id|cpumask_t}} or CPU affinity list: {{The Linux Kernel/id|cpulist_parse}}.


⚲ API
: {{The Linux Kernel/man|1|taskset}} &amp;ndash; set or retrieve a process's CPU affinity
: grep Cpus_allowed /proc/self/status
: {{The Linux Kernel/man|2|sched_setaffinity}} {{The Linux Kernel/man|2|sched_getaffinity}} &amp;ndash; set and get a thread's CPU affinity mask
:: ↪ {{The Linux Kernel/id|sched_setaffinity}}
: {{The Linux Kernel/id|set_cpus_allowed_ptr}} &amp;ndash; common kernel function to change a task's affinity mask
: {{The Linux Kernel/include|linux/cpu_rmap.h}} &amp;ndash; CPU affinity reverse-map support
: {{The Linux Kernel/include|linux/cpumask_types.h}}
:: struct cpumask, {{The Linux Kernel/id|cpumask_t}} &amp;ndash; CPUs bitmap, can be very big
:: {{The Linux Kernel/id|cpumask_var_t}} &amp;ndash; type for local cpumask variable, see {{The Linux Kernel/id|alloc_cpumask_var}}, {{The Linux Kernel/id|free_cpumask_var}}.
: {{The Linux Kernel/include|linux/cpumask.h}} &amp;ndash; Cpumasks provide a bitmap suitable for representing the set of CPU's in a system, one bit position per CPU number
:: {{The Linux Kernel/id|for_each_possible_cpu}}
:: {{The Linux Kernel/id|num_online_cpus}}
:: {{The Linux Kernel/id|cpumask_set_cpu}}
:: {{The Linux Kernel/id|cpumask_test_cpu}}
:: {{The Linux Kernel/id|for_each_cpu}}


⚙️ Internals
: {{The Linux Kernel/id|cpus_mask}} &amp;ndash; affinity of {{The Linux Kernel/id|task_struct}}
: {{The Linux Kernel/id|cpus_allowed}} &amp;ndash; affinity of {{The Linux Kernel/id|cpuset}}


📚 Further reading
: {{w|Processor affinity}}
: {{w|Affinity mask}}

==== CPU hotplug ====

CPU hotplugging in Linux refers to the ability to dynamically add or remove CPUs from the system without needing a reboot.
This feature is crucial in environments requiring high availability and resource flexibility, such as data centers, virtualized systems, and systems that use power management aggressively.


🗝️ Acronyms
: BP &amp;ndash; Bootstrap Processor
: AP &amp;ndash; Application Processor


⚲ API
: /sys/devices/system/cpu/cpu*/online
: /sys/devices/system/cpu/cpu*/hotplug/
: {{The Linux Kernel/include|linux/cpu.h}}
:: {{The Linux Kernel/id|add_cpu}} ...
: {{The Linux Kernel/include|linux/cpuhotplug.h}}
:: {{The Linux Kernel/id|cpuhp_state}} &amp;ndash; CPU hotplug states 
:: {{The Linux Kernel/id|cpuhp_setup_state}} ... &amp;ndash; setups hotplug state callbacks
::: {{The Linux Kernel/id|cpuhp_setup_state_multi}}
::: {{The Linux Kernel/id|cpuhp_setup_state_nocalls}}
: {{The Linux Kernel/include|linux/cpuhplock.h}} &amp;ndash; CPU hotplug locking
:: {{The Linux Kernel/id|cpus_read_lock}} ...
:: {{The Linux Kernel/id|remove_cpu}} ...


⚙️ Internals
: {{The Linux Kernel/source|kernel/cpu.c}} &amp;ndash; CPU hotplug state machine
:: {{The Linux Kernel/id|cpuhp_state}} &amp;ndash; from CPUHP_OFFLINE to CPUHP_AP_ACTIVE and CPUHP_ONLINE.
:: {{The Linux Kernel/id|cpuhp_hp_states}}
:: {{The Linux Kernel/id|boot_cpu_hotplug_init}}
:: {{The Linux Kernel/id|cpuhp_threads_init}}
:: ... {{The Linux Kernel/id|cpuhp_invoke_callback_range}} ...
: {{The Linux Kernel/source|kernel/irq/cpuhotplug.c}} &amp;ndash; IRQ migration on CPU hotunplug
: {{The Linux Kernel/source|drivers/base/cpu.c}} &amp;ndash; CPU subsystem support
:: {{The Linux Kernel/id|cpu_dev_init}}
::: ... {{The Linux Kernel/id|cpu_subsys_online}}
: {{The Linux Kernel/include|trace/events/cpuhp.h}}
: {{The Linux Kernel/include|linux/cpuhplock.h}}


👁️ Examples
: {{The Linux Kernel/id|torture_onoff}}
: {{The Linux Kernel/source|tools/testing/selftests/sched_ext/hotplug.c}} &amp;ndash; sched_ext CPU hotplug test


📖 References
: {{The Linux Kernel/doc|CPU hotplug in the Kernel|core-api/cpu_hotplug.html}}
:: {{The Linux Kernel/doc|Introduction|core-api/cpu_hotplug.html#introduction}} 
:: {{The Linux Kernel/doc|Command Line Switches|core-api/cpu_hotplug.html#command-line-switches}} 
:: {{The Linux Kernel/doc|CPU maps|core-api/cpu_hotplug.html#cpu-maps}} 
:: {{The Linux Kernel/doc|Using CPU hotplug|core-api/cpu_hotplug.html#using-cpu-hotplug}} 
:: {{The Linux Kernel/doc|The CPU hotplug coordination|core-api/cpu_hotplug.html#the-cpu-hotplug-coordination}} 
:: {{The Linux Kernel/doc|The CPU hotplug API|core-api/cpu_hotplug.html#the-cpu-hotplug-api}} 
::: {{The Linux Kernel/doc|CPU hotplug state machine|core-api/cpu_hotplug.html#cpu-hotplug-state-machine}} 
::: {{The Linux Kernel/doc|CPU online/offline operations|core-api/cpu_hotplug.html#cpu-online-offline-operations}} 
::: {{The Linux Kernel/doc|Allocating a state|core-api/cpu_hotplug.html#allocating-a-state}} 
::: {{The Linux Kernel/doc|Setup of a CPU hotplug state|core-api/cpu_hotplug.html#setup-of-a-cpu-hotplug-state}} 
::: {{The Linux Kernel/doc|Removal of a CPU hotplug state|core-api/cpu_hotplug.html#removal-of-a-cpu-hotplug-state}} 
::: {{The Linux Kernel/doc|Multi-Instance state instance management|core-api/cpu_hotplug.html#multi-instance-state-instance-management}} 
::: {{The Linux Kernel/doc|Examples|core-api/cpu_hotplug.html#examples}} 
:: {{The Linux Kernel/doc|Testing of hotplug states|core-api/cpu_hotplug.html#testing-of-hotplug-states}} 
:: {{The Linux Kernel/doc|Architecture’s requirements|core-api/cpu_hotplug.html#architecture-s-requirements}} 
:: {{The Linux Kernel/doc|User Space Notification|core-api/cpu_hotplug.html#user-space-notification}} 
:: {{The Linux Kernel/doc|Kernel Inline Documentations Reference|core-api/cpu_hotplug.html#kernel-inline-documentations-reference}}
 

🔨 [https://manpages.ubuntu.com/manpages/resolute/man1/stress-ng.1.html#:~:text=%2D%2Dcpu%2Donline stress-ng --cpu-online]

📚 Further reading
: {{The Linux Kernel/id|CONFIG_CPU_HOTPLUG_STATE_CONTROL}} &amp;ndash; enables the ability to write incremental steps between &quot;offline&quot; and &quot;online&quot; states to the CPU's sysfs target file, allowing for more granular control of state transitions.
:: {{The Linux Kernel/id|target_store}}: {{The Linux Kernel/id|cpu_up}}/{{The Linux Kernel/id|cpu_down}}
: [https://lore.kernel.org/lkml/?q=cpuhotplug+OR+cpuhp cpuhotplug, cpuhp @LKML]

==== CPU isolation ====

CPU isolation ensures that specific tasks run on dedicated CPUs, reducing contention and latency.

'''Housekeeping''' CPUs refer to the CPUs that are reserved for various '''system''' tasks. See {{The Linux Kernel/id|hk_type}}.

'''Isolated''' CPUs are dedicated to '''real-time''' applications, such as DPDK.

⚲ API
: /sys/devices/system/cpu/isolated
: /sys/devices/system/cpu/nohz_full
: [https://docs.kernel.org/admin-guide/cgroup-v2.html#:~:text=cpuset.cpus.isolated /sys/fs/cgroup/cpuset.cpus.isolated]
: [https://docs.kernel.org/admin-guide/cgroup-v2.html#:~:text=Partition%20root%20without%20load%20balancing /sys/fs/cgroup/.../cpuset.cpus.partition]
: {{The Linux Kernel/include|linux/sched/isolation.h}}
:: {{The Linux Kernel/id|hk_type}} &amp;ndash; housekeeping type
:: {{The Linux Kernel/id|housekeeping_cpumask}} &amp;ndash; returns CPUs available for housekeeping of a given type
:: {{The Linux Kernel/id|cpu_is_isolated}}
: {{The Linux Kernel/include|linux/cpuset.h}} &amp;ndash; cpuset interface
: {{The Linux Kernel/man|7|cpuset}} &amp;ndash; confine processes to processor and memory node subsets


⚙️ Internals
: {{The Linux Kernel/id|CONFIG_CPU_ISOLATION}}
:: {{The Linux Kernel/source|kernel/sched/isolation.c}} &amp;ndash; housekeeping CPU management
::: {{The Linux Kernel/id|housekeeping_init}}, {{The Linux Kernel/id|housekeeping_update}}
: {{The Linux Kernel/id|CONFIG_CPUSETS}}
:: {{The Linux Kernel/source|kernel/cgroup/cpuset.c}} &amp;ndash; cpuset cgroup controller
::: {{The Linux Kernel/id|cpuset_init}}
::: {{The Linux Kernel/id|cpuset_init_smp}}
::: {{The Linux Kernel/id|isolated_cpus}}
::: {{The Linux Kernel/id|partition_xcpus_add}}, {{The Linux Kernel/id|partition_xcpus_del}}


📖 References
: {{The Linux Kernel/doc|CPU lists in command-line parameters|admin-guide/kernel-parameters.html#cpu-lists}}
:: [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=nohz_full= '''nohz_full'''] clears housekeeping.{{The Linux Kernel/id|cpumasks}} for tick, wq, timer, rcu, misc, and kthread in {{The Linux Kernel/id|housekeeping_nohz_full_setup}}
:: [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=isolcpus '''isolcpus'''] clears housekeeping.{{The Linux Kernel/id|cpumasks}} for [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=domain%20isolation domain] (by default), [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=nohz nohz], and [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=managed_irq managed_irq] in {{The Linux Kernel/id|housekeeping_isolcpus_setup}}
: {{The Linux Kernel/doc|Housekeeping|core-api/housekeeping.html}}
: {{The Linux Kernel/doc|NO_HZ: Reducing Scheduling-Clock Ticks|timers/no_hz.html}}
: {{The Linux Kernel/doc|CPUSETS of cgroup v2|admin-guide/cgroup-v2.html#cpuset}}
: {{The Linux Kernel/doc|CPUSETS of cgroup v1|admin-guide/cgroup-v1/cpusets.html}}


📚 Further reading
: [https://www.youtube.com/watch?v=1lomUhSS82s CPU Isolation state of the art, LPC'23]
: [https://lpc.events/event/19/contributions/2219/ CPU Isolation and IPI interference, LPC'25]
: [https://www.suse.com/c/cpu-isolation-introduction-part-1/ CPU Isolation]
: [https://lore.kernel.org/lkml/?q=isolcpus isolcpus @LKML]
: [https://lore.kernel.org/lkml/?q=housekeeping housekeeping @LKML]
: [https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#explicitly-reserved-cpu-list Explicitly Reserved CPU List, Kubernetes Documentation]
: [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cpu-partitioning/start CPU Partitioning]
: {{The Linux Kernel/doc|Scheduler Domains|scheduler/sched-domains.html}} &amp;ndash; the Scheduler balances CPUs (scheduling groups) within a sched domain
: [https://lore.kernel.org/lkml/?q=nohz_full nohz_full @LKML]

💾 Historical since v7.0
: {{The Linux Kernel/id|cpuset_cpu_is_isolated}} &amp;ndash; removed, use {{The Linux Kernel/id|cpu_is_isolated}} instead

=== Runtime code patching ===

The kernel patches its own machine code at boot or runtime to optimize hot paths.
Static keys patch a {{w|NOP_(code)|NOP}} to a jump (or vice versa); static calls patch indirect calls to direct calls; alternatives replace instructions based on CPU features.

⚲ API
: {{The Linux Kernel/include|linux/jump_label.h}} &amp;ndash; static keys
:: {{The Linux Kernel/id|DEFINE_STATIC_KEY_FALSE}} &amp;ndash; define a key, initially false
:: {{The Linux Kernel/id|static_branch_unlikely}} &amp;ndash; zero-cost branch check (NOP when key is false)
:: {{The Linux Kernel/id|static_branch_enable}} &amp;ndash; patch all sites to take the branch (expensive, rare use)
: {{The Linux Kernel/include|linux/static_call.h}} &amp;ndash; static calls
:: {{The Linux Kernel/id|DEFINE_STATIC_CALL}} &amp;ndash; define a call site with initial target function
:: {{The Linux Kernel/id|static_call}} &amp;ndash; invoke the patched direct call
:: {{The Linux Kernel/id|static_call_update}} &amp;ndash; change target function, patch all sites
: {{The Linux Kernel/source|arch/x86/include/asm/alternative.h}} &amp;ndash; alternatives
:: {{The Linux Kernel/id|ALTERNATIVE}} &amp;ndash; replace instructions at boot based on CPU features
:: {{The Linux Kernel/source|arch/x86/include/asm/cpufeatures.h}} &amp;ndash; X86_FEATURE_* flags


⚙️ Internals
: {{The Linux Kernel/id|CONFIG_JUMP_LABEL}}
:: {{The Linux Kernel/source|kernel/jump_label.c}} &amp;ndash; static key patching core
:: {{The Linux Kernel/source|arch/x86/kernel/jump_label.c}} &amp;ndash; x86 static key patching
: {{The Linux Kernel/id|CONFIG_HAVE_STATIC_CALL}}
:: {{The Linux Kernel/source|kernel/static_call_inline.c}} &amp;ndash; static call core
:: {{The Linux Kernel/source|arch/x86/kernel/static_call.c}} &amp;ndash; x86 static call patching
: {{The Linux Kernel/source|arch/x86/include/asm/alternative.h}} &amp;ndash; runtime instruction patching
:: {{The Linux Kernel/source|arch/x86/kernel/alternative.c}} &amp;ndash; x86 alternatives engine
::: {{The Linux Kernel/id|smp_text_poke_single}} &amp;ndash; safely patch code on SMP using INT3 breakpoints; used by static keys, static calls, ftrace, kprobes
:::: {{The Linux Kernel/id|smp_text_poke_batch_add}}
:::: {{The Linux Kernel/id|smp_text_poke_batch_finish}}


👁 Examples
: {{The Linux Kernel/id|housekeeping_overridden}}
: {{The Linux Kernel/id|preempt_schedule}}
: tracepoints


📖 References
: {{The Linux Kernel/doc|Static Keys|staging/static-keys.html}}
: {{The Linux Kernel/doc|x86 CPU feature flags|arch/x86/cpuinfo.html}}


=== {{w|Memory barrier}}s ===

Memory barriers (MB) are synchronization mechanisms used to ensure proper ordering of memory operations in a SMP environment.
They play a crucial role in maintaining the consistency and correctness of data shared among different CPU cores or processors.
MBs prevent unexpected and potentially harmful reordering of memory access instructions by the compiler or CPU, which can lead to data corruption and race conditions in a concurrent software system.

⚲ API
: {{The Linux Kernel/man|2|membarrier}}
: {{The Linux Kernel/include|asm-generic/barrier.h}}
:: {{The Linux Kernel/id|mb}}, {{The Linux Kernel/id|rmb}}, {{The Linux Kernel/id|wmb}}
:: {{The Linux Kernel/id|smp_mb}}, {{The Linux Kernel/id|smp_rmb}}, {{The Linux Kernel/id|smp_wmb}}


⚙️ Internals

: {{The Linux Kernel/source|arch/x86/include/asm/barrier.h}} &amp;ndash; x86 memory barrier instructions
: {{The Linux Kernel/source|kernel/sched/membarrier.c}} &amp;ndash; membarrier system call


📖 References
: {{The Linux Kernel/doc|Memory barriers|core-api/wrappers/memory-barriers.html}}


=== States ===

C-states and P-states are features in modern CPUs designed to improve energy efficiency.

🗝️ Acronyms
: [https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/08_Processor_Configuration_and_Control/processor-power-states.html C-states] &amp;ndash; CPU(?) states, aka idle states
: EPP &amp;ndash; {{The Linux Kernel/doc|Energy Performance Preference|admin-guide/pm/amd-pstate.html#energy-performance-preference-epp-rw}}
: HWP &amp;ndash; hardware-managed P-states, see [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=hwp_only hwp_only]
: [https://www.intel.com/content/www/us/en/docs/socwatch/user-guide/2020/p-state.html P-states] &amp;ndash; Performance states, see CPU Power and frequency scaling


⚲ API
: [https://linux.die.net/man/1/cpupower cpupower]


📖 References
: {{The Linux Kernel/doc|Working-State Power Management|admin-guide/pm/working-state.html}}
: https://lwn.net/Kernel/Index/#Power_management


==== Idle ====


C-states, {{w|ACPI#Processor_states|power states}}:
: C0 – operating, executing instructions.
: C1 (Halt) – internal {{w|Clock gating|clocks stopped}}.
: C1E (Enhanced Halt) – clocks stopped, voltage and frequency reduced.
: C2 (Stop-Clock) – internal and external {{w|Clock gating|clocks stopped}}.
: C3 (Deep Sleep) – clocks stopped, L1/L2 cache may flush, local APIC timer stops, requiring [[#Clock_infrastructure|tick broadcast]].
: C4 (Deeper Sleep) – voltage reduced.
: C6 (Deep Power Down) – state saved to SRAM, voltage can drop to 0V.
: C7 (Deeper Power Down) – C6 + L3 cache flushed.
: Modern Intel typically uses C1/C1E and C6, skipping C2–C5.
: ⚠️ ACPI state names (C1_ACPI, C2_ACPI, C3_ACPI) may not match actual hardware C-states. The [https://www.felixcloutier.com/x86/monitor:mwait MWAIT] hint reveals the real state: e.g. MWAIT 0x60 = hardware C6 may appear as &quot;C3_ACPI&quot;.


⚲ API
: turbostat --show CPU --quiet -n 1 --interval 0.1 --show sysfs
: [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=idle= idle=]
: /dev/cpu_dma_latency &amp;ndash; see {{The Linux Kernel/id|set_cpu_dma_latency}}
: C-states interfaces:
:: cpupower idle-info – show driver, governor, states with latency and residency
:: /sys/devices/system/cpu/cpuidle/
:: /sys/devices/system/cpu/cpu*/cpuidle/
::: cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name – list available C-states
:: {{The Linux Kernel/include|linux/cpuidle.h}} – generic framework for CPU idle power management
: {{The Linux Kernel/include|linux/pm_qos.h}}


⚙️ Internals
: {{The Linux Kernel/source|drivers/cpuidle}} – CPU idle governors and drivers
: {{The Linux Kernel/source|drivers/idle/intel_idle.c}} – {{The Linux Kernel/doc|intel_idle|admin-guide/pm/intel_idle.html}}, hardcoded C-states per CPU model, modern Intel (C1/C1E/C6)
: {{The Linux Kernel/source|drivers/acpi/processor_idle.c}} – acpi_idle, reads C-states from ACPI tables, generic fallback (C1/C2/C3)
: {{The Linux Kernel/source|kernel/power/qos.c}} – PM quality of service
:: {{The Linux Kernel/id|cpu_latency_qos_miscdev}} – implementation of /dev/cpu_dma_latency


📖 References
:: {{The Linux Kernel/doc|CPU Idle Time Management|admin-guide/pm/cpuidle.html}}
: [https://www.intel.com/content/www/us/en/support/articles/000006619/processors/intel-core-processors.html Intel C-states reference]
: [https://support.hpe.com/hpesc/public/docDisplay?docId=sd00002067en_us&amp;page=GUID-855C475E-F9F9-460D-9475-B96DD982B587.html HPE C-states reference]


📚 Further reading
:: https://lwn.net/Kernel/Index/#Power_management-cpuidle
: {{The Linux Kernel/doc|PM Quality Of Service Interface|power/pm_qos_interface.html}}

==== Power and frequency ====


P-states, {{w|ACPI#Performance_state|performance states}}:
: P0 &amp;ndash; maximum power and frequency
: Pn &amp;ndash; less power and frequency
: ...


⚲ API
: Reliable measurement of actual CPU frequency
:: [https://manpages.debian.org/testing/linux-cpupower/turbostat.8.en.html turbostat] --quiet --show CPU,Bzy_MHz -n 1 --interval 0.1
::: Bzy_MHz &amp;ndash; average clock rate while the CPU was not idle (ie. in &quot;c0&quot; state).
: [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=intel_pstate intel_pstate=]
:: {{The Linux Kernel/doc|Kernel Command Line Options for intel_pstate|admin-guide/pm/intel_pstate.html#kernel-command-line-options-for-intel-pstate}}
: [https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt#:~:text=cpufreq.default_governor cpufreq.default_governor=]
: P-states interfaces:
:: /sys/devices/system/cpu/cpufreq/
:: /sys/devices/system/cpu/cpu*/cpufreq/
::: scaling_cur_freq &amp;ndash; unreliable assumption on CPU frequency
:: /sys/devices/system/cpu/intel_pstate/
:: {{The Linux Kernel/include|linux/cpufreq.h}}
:: {{The Linux Kernel/include|linux/sched/cpufreq.h}} &amp;ndash; interface between cpufreq drivers and the scheduler


⚙️ Internals
: {{The Linux Kernel/source|drivers/cpufreq}} &amp;ndash; CPU frequency scaling drivers
:: {{The Linux Kernel/id|intel_pstate}}
:: {{The Linux Kernel/id|acpi_cpufreq_driver}}
: {{The Linux Kernel/source|kernel/sched/cpufreq_schedutil.c}} &amp;ndash; implementation of cpufreq.default_governor=schedutil
: {{The Linux Kernel/source|arch/x86/kernel/cpu/intel_epb.c}} &amp;ndash; Intel Performance and Energy Bias Hint support


📖 References
: {{The Linux Kernel/doc|CPU Performance Scaling|admin-guide/pm/cpufreq.html}}
: {{The Linux Kernel/doc|Device Frequency Scaling|driver-api/devfreq.html}}
: [https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt CPUFreq Governor]
: {{The Linux Kernel/doc|CPUFreq - CPU frequency and voltage scaling|cpu-freq}}
: {{The Linux Kernel/doc|Intel Performance and Energy Bias Hint|admin-guide/pm/intel_epb.html}}
: {{The Linux Kernel/doc|intel_pstate CPU Performance Scaling Driver|admin-guide/pm/intel_pstate.html}}
:: {{The Linux Kernel/doc|General Information|admin-guide/pm/intel_pstate.html#general-information}} 
:: {{The Linux Kernel/doc|Operation Modes|admin-guide/pm/intel_pstate.html#operation-modes}} 
::: {{The Linux Kernel/doc|Active Mode|admin-guide/pm/intel_pstate.html#active-mode}}
&lt;!--
:::: {{The Linux Kernel/doc|Active Mode With HWP|admin-guide/pm/intel_pstate.html#active-mode-with-hwp}} 
::::: {{The Linux Kernel/doc|HWP + performance|admin-guide/pm/intel_pstate.html#hwp-performance}} 
::::: {{The Linux Kernel/doc|HWP + powersave|admin-guide/pm/intel_pstate.html#hwp-powersave}} 
:::: {{The Linux Kernel/doc|Active Mode Without HWP|admin-guide/pm/intel_pstate.html#active-mode-without-hwp}} 
::::: {{The Linux Kernel/doc|performance|admin-guide/pm/intel_pstate.html#performance}} 
::::: {{The Linux Kernel/doc|powersave|admin-guide/pm/intel_pstate.html#powersave}} 
--&gt;
::: {{The Linux Kernel/doc|Passive Mode|admin-guide/pm/intel_pstate.html#passive-mode}} 
:: {{The Linux Kernel/doc|Turbo P-states Support|admin-guide/pm/intel_pstate.html#turbo-p-states-support}} 
:: {{The Linux Kernel/doc|Processor Support|admin-guide/pm/intel_pstate.html#processor-support}} 
:: {{The Linux Kernel/doc|Support for Hybrid Processors|admin-guide/pm/intel_pstate.html#support-for-hybrid-processors}} 
::: {{The Linux Kernel/doc|Hybrid Processors with SMT|admin-guide/pm/intel_pstate.html#hybrid-processors-with-smt}} 
::: {{The Linux Kernel/doc|Capacity-Aware Scheduling Support|admin-guide/pm/intel_pstate.html#capacity-aware-scheduling-support}} 
::: {{The Linux Kernel/doc|Energy-Aware Scheduling Support|admin-guide/pm/intel_pstate.html#energy-aware-scheduling-support}} 
:: {{The Linux Kernel/doc|User Space Interface in sysfs|admin-guide/pm/intel_pstate.html#user-space-interface-in-sysfs}} 
::: {{The Linux Kernel/doc|Global Attributes|admin-guide/pm/intel_pstate.html#global-attributes}} 
::: {{The Linux Kernel/doc|Interpretation of Policy Attributes|admin-guide/pm/intel_pstate.html#interpretation-of-policy-attributes}} 
::: {{The Linux Kernel/doc|Coordination of P-State Limits|admin-guide/pm/intel_pstate.html#coordination-of-p-state-limits}} 
::: {{The Linux Kernel/doc|Energy vs Performance Hints|admin-guide/pm/intel_pstate.html#energy-vs-performance-hints}} 
:: {{The Linux Kernel/doc|intel_pstate vs acpi-cpufreq|admin-guide/pm/intel_pstate.html#intel-pstate-vs-acpi-cpufreq}} 
:: {{The Linux Kernel/doc|Kernel Command Line Options for intel_pstate|admin-guide/pm/intel_pstate.html#kernel-command-line-options-for-intel-pstate}} 
:: {{The Linux Kernel/doc|Diagnostics and Tuning|admin-guide/pm/intel_pstate.html#diagnostics-and-tuning}} 
::: {{The Linux Kernel/doc|Trace Events|admin-guide/pm/intel_pstate.html#trace-events}} 
::: {{The Linux Kernel/doc|ftrace|admin-guide/pm/intel_pstate.html#ftrace}} 
&lt;!-- end of intel_pstate.html --&gt;


📚 Further reading
: https://lwn.net/Kernel/Index/#Power_management-Frequency_scaling
: [https://wiki.archlinux.org/title/CPU_frequency_scaling CPU frequency scaling]
: {{The Linux Kernel/ltp|kernel/device-drivers|cpufreq}}
: [https://www.thinkwiki.org/wiki/How_to_use_cpufrequtils How to use cpufrequtils] 
:: [https://linux.die.net/man/1/cpufreq-info cpufreq-info]
:: [https://linux.die.net/man/1/cpufreq-set cpufreq-set]
: https://github.com/intel/power-optimization-library
: https://github.com/intel/kubernetes-power-manager

{{BookCat}}</text>
      <sha1>3inpn5leseefzs5jg3mcjk4jfg5hqv4</sha1>
    </revision>
  </page>
  <page>
    <title>General Literary Chinese from Scratch</title>
    <ns>0</ns>
    <id>481710</id>
    <revision>
      <id>4657090</id>
      <parentid>4656700</parentid>
      <timestamp>2026-08-10T19:42:11Z</timestamp>
      <contributor>
        <username>Shira the Mogul</username>
        <id>3560559</id>
      </contributor>
      <minor />
      <comment>/* Unit 16: Nation Focus - Vietnam */</comment>
      <origin>4657090</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="35727" sha1="pndanv928aq20noultrg79tupultqx9" xml:space="preserve">__notoc__

Welcome to the Wikibook for Literary Chinese (Known as 漢文 &quot;Han Language&quot; in East Asia or 文言 &quot;Literary Language&quot; in China), aimed at individuals hoping to gain a general knowledge of it before progressing into genres they wish to be acquainted with. 

This is not the [[Classical Chinese]] textbook, which is aimed at Chinese Zhou-Qin era texts. This  text aims to shed light on post-Zhou-Qin texts across East Asia, which mimic those texts. However, as Zhou-Qin era texts served as the main body from which individuals learned, they are employed here as and when they are considered necessary or otherwise useful. It does so through a &quot;buffet&quot; approach, showering you, the reader, with an ocean of texts of myriad genre. 

==Table of Contents==

=== Front matter ===

* [[/Introduction/]]
* [[/Appendices/]]

=== Useful resources ===
These are quick grab-bags that can be useful for vocabulary-building. 
* [[/Antonym List/]] &lt;!--- 文/武，大/小，厚/薄，橫/縱...---&gt;
* [[/Collocation Groups/]] &lt;!--- e.g. 四象，三靈…… ---&gt;
* [[/Pronoun Table/]]
* [https://zh.wikiversity.org/wiki/Subject:華製新漢語及中文固有語/嚴譯及部定詞等 Yan Fu's Qing-era translations for modern terms] &lt;!--- Wikiversity has this (https://zh.wikiversity.org/wiki/Subject:華製新漢語及中文固有語/嚴譯及部定詞等) and the below, I will effectively be translating a lot of it! ---&gt;
* [https://zh.wikiversity.org/wiki/Subject:華製新漢語及中文固有語/上古語考輯 Communicative Terms]
&lt;!--- this will be translated eventually, but right now it's bad to just leave this here. ---&gt;

=== Useful primers ===
Across history, many primers have been made for teaching Literary Chinese to children. These are a few that are recommended for use alongside this work, ideally in flashcards. 
* [https://www.fdgwz.org.cn/Web/Show/11308 倉頡篇] - Cangjie's Chapters, the earliest one. It is extant, but incomplete. It contains several rare characters, and so if used, I would personally recommend doing so later, or out of interest. 
* 三字經 - The Three Character Classic, an excellent piece for Confucian education. Pair with 弟子规 for best results. 
** 三字經（太平天國版）- For Christians, there is a version made by Hong Xiuquan from the Taiping Rebellion. Despite the context, it is a legitimately useful primer and can be used to self-teach for the Delegate's Edition of the Christian Bible. 
* 千字文 - The Thousand Character Classic, a remarkable piece of constrained writing that only uses each character once. Amazing for building vocabulary whilst seeing historical allusions and the like. 
* 五字鑑 - The Five-Character Mirror, essentially the 24 Histories of China compressed into a primer. Uses 5-character couplets, the longest in this list. 
* 龍文鞭影 - The Shadow of Longwen's Whip, a historical allusion trainer. Best paired with a context piece.

===Unit 0: The Han script===
This unit is intended for those with no familiarity of the Han script. It will prepare you for the units ahead, teaching largely pictographic characters. 

By the end of this unit, students will:
* Recognise around 50 characters.
* Understand how characters are composed and how this gives them meaning.
* Have a basic idea of how to handwrite and/or type characters using the Cangjie Input Method.
* Know some bare basics of Literary Chinese grammar (e.g. Basic word order, where adjectives go, lack of &quot;is&quot;, 有...)

Lessons:
# [[/An Introduction to the Han Script/]]
# [[/People, Big and Small/]]
# [[/How do we write Chinese?/]]
# [[/What are Chinese characters, anyway?/]]
# [[/The Sun, the Moon, and the Five Elements/]]
# [[/Getting Familiar with Body Parts/]]
# [[/Using Numbers and Using Weapons/]] &lt;!--- 竹戈十大中一弓廿卜---&gt;
# [[/Tilling the Fields with 有/]] &lt;!--- 山田 ---&gt;
# [[/How Characters are Made/|How Characters are Made with Kiyohara no Sanemoto]] 
# [[/Cangjie Created Characters/]] &lt;!--- Get people to use Cangjie ---&gt;
# [[/The Kangxi Radical System/]] &lt;!--- Introduce some monoradical texts to train recognition. ---&gt;

===Unit 1: Basic Skills===
This unit is intended for those with minimal familiarity with the Han script and no familiarity with Literary Chinese. There is a focus on simple structures, skills for dissecting common textual structures, and short-form poetry in this unit. 

Before starting this unit, students should:
* Recognise around ~30 characters. 
* Can use Cangjie input. 
* Have given Unit 0 a cursory glance. 
&lt;br&gt;
By the end of this unit, students will:
* Recognise around ~100 characters. 
* Comprehend numbers, the Heavenly Stems, and the Earthly Branches, and be able to use them to quantify time and date.
* Intuit the basic topic -&gt; comment idea behind Literary Chinese. &quot;This, it is...&quot; 
* Understand basic function words such as 也, 而, 有, and 謂.

Lessons:
# [[/The All-Purpose 也/]]
# [[/An Introduction to Chinese Numbers/]] &lt;!--- It is hard to find authentic materials for this ---&gt;
# [[/One, Two, Left, and Right with Gongsun Long/]]
&lt;!---
曰：「二有一乎？」

曰：「二無一。」

曰：「二有右乎？」

曰：「二無右。」

曰：「二有左乎？」

曰：「二無左。」

曰：「右可謂二乎？」

曰：「不可。」

曰：「左可謂二乎？」

曰：「不可。」

曰：「左與右可謂二乎？」

曰：「可。」
---&gt;
# [[/The Heavenly Stems/]] &lt;!--- Introduce ordinals, which will be used to demonstrate sentence patterns later. ---&gt;
# [[/Tell the Time with Earthly Branches/]] &lt;!--- Introduce verbs and timekeeping ---&gt;
# [[/Lunar Dates with the Spring and Autumn Annals/]]
&lt;!--- Vocabulary: 歲，年，朔，月，日，來，前，初，正，春秋夏冬，曆，上，下. Consider including traditional names for months in a list. ---&gt;
# [[/Skimming for Major Events in Historical Annals/]] 
&lt;!--- Don't simply use Confucius's Chunqiu: We can use texts inspired by it. 

E.g. 三國史記 - 十五年京城旱。秋七月，蝗。very few new characters, lots one can use. Instantly able to use. 
https://zh.wikisource.org/wiki/%E4%B8%89%E5%9C%8B%E5%8F%B2%E8%A8%98/%E5%8D%B701

Skimming annals is very possible and a very useful skill. Don't skip out on it. Teach students to skim read!!! 
---&gt;
# [[/Dinner with the Daimyo/]]
&lt;!-- 
侍宴·大友皇子
皇明光日月，帝徳載天地。
三才併秦昌，万国表臣義。
--&gt; 
# [[/In Discourse with Jibong/]]
&lt;!--
芝峰類說 
倭國謂田爲畠。謂水田爲田。火田爲畑。猶我國以水田爲畓也。故官名有畠山殿。地名有畑島云。
--&gt;
# [[/Shinto FAQ with Honda Chikaatsu/]] 
&lt;!--- https://wikisource.org/wiki/%E7%9C%9E%E9%81%93%E5%95%8F%E5%B0%8D 眞道問對 本田親徳 really good way of operationalising 乎 and much of the early grammar. 

問 天帝無始無終乎。
對 天帝無始無終也。
旣以無始無終之力
與無始無終之體
造無始無終之萬物。
其功亦無始無終也。

問 天地大原在道乎。
對 天地大原實在道。
鬼神依道而立。
人民依道而活。
萬物依道而息。

This is great! ---&gt;

&lt;!---
Some cool stuff I saw someone studying from
https://zh.wikisource.org/wiki/%E8%87%B3%E5%B0%8F%E4%B8%98%E8%A5%BF%E5%B0%8F%E7%9F%B3%E6%BD%AD%E8%A8%98#
https://zh.wikisource.org/wiki/%E6%A0%B8%E8%88%9F%E8%A8%98

Could be used for period focus
---&gt;

===Unit 2: An Overview of Sinitic Poetry===
This unit will teach you how Sinitic Poetry operates; - that is, the way individuals in the Sinosphere compose poetry in Literary Chinese. Despite this language's fall out of favour in the past century, this tradition is still remarkably alive and well, and their short length makes them more accessible than elaborate prose. In this unit, you will begin from the ''Classic of Poetry'' before travelling through poems from the Tang dynasty, Singapore, Japan, Vietnam, the Ryukyu Kingdom, and Korea. When introducing poetry, I will furthermore use the language from the nation it is from to show how it is recited by its people. 

After discussing the Classic of Poetry, we will also be a small detour into a discussion on Ping-Ze 平仄, the Tang dynasty system of alternating tones, so to produce rhyme on tonal and phonological levels. This had a major impact on Literary Chinese poetry as a whole!

By the end of this Unit, students will:
* Recognise around 120 more characters.
* Be able to explain how Sinitic Poetry rhymes and the themes it contains.
* Be able to use function words such as 在, 無, 不, 聿, and 于/於 in poetic contexts.
* Recognise the switch between 吾/我 in the subject-object positions and demonstrate it in usage.
* (Chinese speakers) Be able to differentiate 于 and 於, and understand the &quot;interest(ed) in&quot; meaning of 好 in most circumstances.
&lt;!---
Summary of the above part about 于 and 於 for other editors:
于 and 於 were distinct words for an extremely long time and were still such to Literary Chinese writers. Their &quot;merging&quot; through Simplified-Traditional Chinese distinctions is a very modern thing. I will summarise their usages here, using Pulleyblank's Outline of Classical Chinese Grammar (2000);
* 于 - This can mean &quot;to go&quot; or &quot;to/at&quot;. 黃鳥于飛 &quot;The yellow birds go flying&quot;. Must be post-verbal. It can also appear in 至于.
* 於 - This is an all-purpose locative preposition - from &quot;on/at/in&quot; to &quot;from&quot; or even &quot;than&quot; (甲於乙). The implication of motion is not there at all. Must be pre-verbal. It can also appear in 之於 or be an archaic noun for a crow 於 (烏).
---&gt;

Lessons:
# [[/Across the Rivers with Emperor Puliuru Guang/]] &lt;!--- Illustrate ping-ze ---&gt;
# [[/To Study the Odes/]] 
# [[/A Detour into Orthodox Ping-Ze/]] 
&lt;!--- 平 and 仄 are useful characters themselves. Show 仄 in the binomes 反仄，歉仄，逼仄 as it's often difficult to immediately use ---&gt;
# [[/The Restraint of Du Fu/]] 
# [[/The Longing of Li Bai/]] 
# [[/The Environment with Bukha Timur/]]
# [[/Pillow Talk with Guan Yunshi/]]
&lt;!---
紅繡鞋·貫雲石
挨著靠著雲窗同坐，偎著抱著月枕雙歌，聽著數著愁著怕著早四更過。四更過情未足，情未足夜如梭。天哪，更閏一更兒妨甚么！

Uyghur author!
---&gt;
# [[/Buddhist Philosophy with Ngô Chân Lưu and Taisei Shōan/]]
&lt;!-- 元火·吳真流
木中元有火，元火復還生。
若為木無火，鉆燧何有萌。--&gt;
&lt;!-- 杜鵑·大成聖安
夢覚孤床静
杜鵑帯雨飛
一声来近枕
何者不沾衣
--&gt;
# [[/Odes with Mō Taiei and Zheng Chengxun/]]
&lt;!-- 詠松·毛泰永
植體宜千仞，垂陰動百尋。
李膺真烈烈，和嶠自森森。
桃李何堪較，雪霜安得侵。
萬年身不老，種子又成林。
AKA Inoha Seiki 伊野波 盛紀 --&gt;
&lt;!-- 詠班蘭·鄭成勛
南國多芳草，班蘭最有名。
深根將綠茁，長葉亦叢生。
取味迎賓合，入厨任水烹。
可憐經一用，擲棄不留情。

鄭成勛《樵隱詩集》 https://nus.edu.sg/nuslibraries/dsprojects/sg-jiutishi/poem/827 --&gt;
# [[/A Golden Cup and the Fall of a Dynasty with Yan Fu/]] 
# [[/On a Journey with Sadula/]]
&lt;!---
No lesson entry:
朝中措·襄陽古道灞陵橋
襄陽古道灞陵橋，詩興與秋高。
千古風流人物，一時多少雄豪。

霜清玉塞，雲飛隴首，風落江皋。
夢到鳳凰台上，山圍故國周遭。

北郊晚步
陂水荷凋晚，茅檐燕去涼。
遠林明落景，平麓淡秋光。
群牧歸村巷，孤禽立野航。
自諳閑散樂，園圃意尤長。

Jurchen poet and grandson of Emperor Shizong of Jin. He's a Zen Buddhist, so we'll go back to him later.
---&gt;

===Unit 3: Confucianism and the World===
This is a Confucian-themed unit with a smattering of other items. You will see the odd geography of the past, early linguistic philosophy, and terrifying breakaway states!

By the end of this unit, students should be able to:
* Recognise around 200+ characters.
* Read basic annals and histories with some dictionary assistance, and comprehend 3-character structures reliably.
* Have encountered basic grammatical points such as 之、乎、者、也、而、則、乃、所、以、於、于、與、且、蓋、and 夫. 
** 於 and 于 should be distinguishable.
* Survive a text of at least 250 characters and read for gist.

Lessons:
# [[/A Brief Overview of Confucianism/]] 
# [[/Teaching the Annals in Qi/]] &lt;!-- Gongyang Gao's commentary --&gt;
# [[/Is a White Horse a Horse?/]]&lt;!-- Teach negation with 非 in 公孙龍子 and compare with 不 --&gt;
# [[/The Three Character Classic/]]
# [[/Expressing Filial Conduct with Confucius and Hara Saihin/]]
&lt;!--
次韻杏坪先生
父執有君孤不孤
相依遍接搢紳徒
区区自抱地方寸
杳杳重遊天一隅
羇雁飛鳴迷汝國
家人思夢入江都
如教志業青年遂
世上寧無逐臭夫
--&gt;
# [[/Confucianism and the Environment with Sai On/]]&lt;!-- 木假山記 --&gt;
# [[/In Debate with Mencius/]]

===Unit 4: Women's Writing===
In this unit, women's writing from various areas of China will be explored. This is chiefly targeted at poetry and the themes within; from the feminine voice of the Classic of Poetry to the remonstrance towards the Khitan Emperor Tianzuo of Jin by his Consort Dasese. The role of women in courtly society is to be elucidated here!
# [[/An Unmarried Life with Heo Nansŏrhŏn/]]
&lt;!---
貧女吟 
豈是乏容色。工鍼復工織。
少小長寒門。良媒不相識。

夜久織未休。戛戛鳴寒機。
機中一匹練。終作阿誰衣。

手把金翦刀。夜寒十指直。
爲人作嫁衣。年年還獨宿。
---&gt;
# [[/Responding to Lord Trần with Hồ Xuân Hương/]]
&lt;!---
Responding to 陳光靜 Trần Quang Tĩnh

《和陳侯》
愧無才調使人驚，十載風塵貫耳鈴。
已是臨枰知敵手，莫須敲月苦殫精。
為輪為彈隨遭遇，誰鳳誰鶯任賦生。
造物於人何苟惜，明珠休向暗中呈。

莫須 is an important structure to teach here.
---&gt;
# [[/Gaze into the Autumn Night with Taisei Shōan/]]
&lt;!---
秋夜偶成·大成聖安
長天浮爽気，月色興無窮
群犬吠山径，百蟲啼野風
悲秋秋夜永，感古古今同
自是孤窓下，凄然万慮空
---&gt;
# [[/Visiting a Temple with Yu Xuanji/]]
&lt;!---
遊崇真觀南樓覩新及第題名處
雲峰滿目放春晴，歷歷銀鈎指下生。
自恨羅衣掩詩句，擧頭空羨榜中名。
---&gt;
# [[/Remonstrance with Dasese/]]
&lt;!---
https://zh.wikisource.org/wiki/%E8%AB%B7%E8%AB%AB%E6%AD%8C
諷諫歌·大瑟瑟
勿嗟塞上兮暗紅塵。
勿傷多難兮畏夷人。
不如塞奸邪之路兮選取賢臣。
直須臥薪嚐膽兮激壯士之捐身。
可以朝清漠北兮夕枕燕雲。

Dasese (or 萧瑟瑟) was a Khitan consort to Emperor Tianzuo of Liao. She remonstrated him as the Jurchens were beginning to encroach upon the Khitan, and was forced to commit suicide for her remonstrance. Tianzuo would soon pay for his malfeasance. 
---&gt;
# [[/The Love Songs of the Odes/]]
&lt;!---
褰裳
子惠思我，褰裳涉溱。子不我思，豈無他人？狂童之狂也且！
子惠思我，褰裳涉洧。子不我思，豈無他士？狂童之狂也且！

柏舟
彼柏舟，在彼中河，髧彼兩髦，實維我儀，之死矢靡它，母也天只，不諒人只。
汎彼柏舟，在彼河側，髧彼兩髦，實維我特，之死矢靡慝，母也天只，不諒人只。

行露
厭浥行露，豈不夙夜，謂行多露。
誰謂雀無角？何以穿我屋？誰謂女無家？何以速我獄？雖速我獄，室家不足。
誰謂鼠無牙？何以穿我墉？誰謂女無家？何以速我訟？雖速我訟，亦不女從。
---&gt;
# [[/Rules for Women with Ban Zhao/]]
&lt;!--- https://zh.wikisource.org/wiki/%E5%A5%B3%E8%AA%A1 ---&gt;
# [[/The Tragedy of Cai Wenji/]]
&lt;!---
悲憤詩
〔兩漢〕蔡文姬
漢季失權柄，董卓亂天常。
志欲圖篡弒，先害諸賢良。
逼迫遷舊邦，擁主以自強。
海內興義師，欲共討不祥。
卓眾來東下，金甲耀日光。
平土人脆弱，來兵皆胡羌。
獵野圍城邑，所向悉破亡。
斬截無孑遺，屍骸相撐拒。
馬邊懸男頭，馬後載婦女。
長驅西入關，迥路險且阻。
還顧邈冥冥，肝脾為爛腐。
所略有萬計，不得令屯聚。
或有骨肉俱，欲言不敢語。
失意幾微間，輒言斃降虜。
要當以亭刃，我曹不活汝。
豈復惜性命，不堪其詈罵。
或便加棰杖，毒痛參並下。
旦則號泣行，夜則悲吟坐。
欲死不能得，欲生無一可。
彼蒼者何辜，乃遭此厄禍。
邊荒與華異，人俗少義理。
處所多霜雪，胡風春夏起。
翩翩吹我衣，肅肅入我耳。
感時念父母，哀嘆無窮已。
有客從外來，聞之常歡喜。
迎問其消息，輒復非鄉里。
邂逅徼時願，骨肉來迎己。
己得自解免，當復棄兒子。
天屬綴人心，念別無會期。
存亡永乖隔，不忍與之辭。
兒前抱我頸，問母欲何之。
人言母當去，豈復有還時。
阿母常仁惻，今何更不慈。
我尚未成人，奈何不顧思。
見此崩五內，恍惚生狂痴。
號泣手撫摩，當發復回疑。
兼有同時輩，相送告離別。
慕我獨得歸，哀叫聲摧裂。
馬為立踟躕，車為不轉轍。
觀者皆噓唏，行路亦嗚咽。
去去割情戀，遄征日遐邁。
悠悠三千里，何時復交會。
念我出腹子，匈臆為摧敗。
既至家人盡，又復無中外。
城廓為山林，庭宇生荊艾。
白骨不知誰，縱橫莫覆蓋。
出門無人聲，豺狼號且吠。
煢煢對孤景，怛吒糜肝肺。
登高遠眺望，魂神忽飛逝。
奄若壽命盡，旁人相寬大。
為復強視息，雖生何聊賴。
託命於新人，竭心自勖勵。
流離成鄙賤，常恐復捐廢。
人生幾何時，懷憂終年歲。
---&gt;

===Unit 5: Myths and Legends of East Asia===
&lt;!--- Shanhaijing, Zibuyu... Etc. Zhiguai literature. This aims to provide a counterpoint to what Confucius wouldn't discuss - thus Zibuyu. Going straight into Daoism isn't ideal. ---&gt;
# [[/Exploring the World of Mountains and Seas/]]&lt;!-- Structure: 出焉 --&gt;
# [[/Oh, the Qilin!/]] &lt;!--- Even here, the odes can be studied! ---&gt;
# [[/The Poison of Zhen/]] &lt;!--- referenced a lot in histories ---&gt;
# [[/Ultimate Justice with Xiezhi/]] &lt;!--- the yellow emperor met one, gao yao also used one ---&gt;
# [[/The Virtue of the Fenghuang/]] &lt;!--- shanhaijing has a great line on this ---&gt;
# [[/The Entrapment of Hua Po/]] 
# [[/Nüwa Created the World/]]

===Unit 6: Nation Focus - Japan===
# [[/The Inariyama Sword/]] 
&lt;!--- short and sweet! ---&gt;
# [[/Entering Japan with Takeda Shingen/]]
# [[/The Oldest Inscription in Japan/]] 
&lt;!--- 宇治橋断碑 ---&gt; 
# [[/The End of a Rebellion/]] 
# [[/Shinto Teachings with Honda Chikaatsu/]] 
&lt;!--- https://wikisource.org/wiki/%E9%81%93%E4%B9%8B%E5%A4%A7%E5%8E%9F 本田親徳 道之大原 ---&gt;  
# [[/The Diary of Fujiwara no Teika/]] &lt;!--- 明月記 ---&gt;
# [[/Reading the History of Japan with Prince Toneri/]] &lt;!--- 日本書記, etc. ---&gt; 
# [[/A Biographical Painting of Toyotomi Hideyoshi/]] &lt;!--- This is on Fanya Hanwen Corpus ---&gt;
&lt;!--- # [[/Occupying Taiwan/]] ---&gt;
&lt;!--- I have some colonial literature on me that can be used here. ---&gt;

===Unit 7: Nation Focus - Korea===
# [[/Feigned Surrender with Ŭlchi Mundŏk/]] &lt;!--- 乙支文德漢詩 ---&gt;
# [[/A fu with Yi Kyubo/]]
# [[/An Elegy to the Empress with Choe Ja/]]
&lt;!---
Choe Ja
元德大后輓詞·崔滋（최자）
乾極曾客配,坤儀正體元。
枕前朝聖主,帳底見曾孫。
陰慘俄沉月,屋悲便沒軒。
三韓千古淚,七十九年恩。
---&gt;
# [[/Language Reform with Sejong the Great/]]
&lt;!--- 訓民正音 https://github.com/ShiraTheMogul/fanyahanwen-corpus/commit/1ef2b42cc50055affaa5ef39c61b87ed31c34a60 multiple poems and descriptive terms, possibly the best capstone ---&gt;
# [[/Fall Off Your Horse!/]] &lt;!--- a famous record from 朝鮮王朝實錄 ---&gt;
# [[/The Diary of Yi Sun-Sin/]] &lt;!--- 亂中日記 ---&gt;
# [[/Tales from Mount Kumo/]] &lt;!--- 金鰲新話 ---&gt;
# [[/Pak Chiwŏn Tours the Qing/]] &lt;!--- 熱河日記 ---&gt;
# [[/Korea's Three Kingdoms/]] &lt;!--- 三國史記 for sure! ---&gt;
# [[/Hwang Yun-seok's Essays/]] &lt;!--- https://zh.wikisource.org/wiki/%E9%A0%A4%E9%BD%8B%E9%81%BA%E7%A8%BF 頤齋遺稿 黃胤錫 Joseon scholar! ---&gt;

===Unit 8: Christian Literature===
# [[/A Different Three Character Classic with Hong Xiuquan/]]
# [[/Friar Juan Cobo's Veritable Record/]] 
&lt;!--- 
One of few texts from the Philippines that I have ever found!
https://bnedigital.bne.es/bd/en/viewer?id=0160187c-9d9b-4f34-84d6-bc03fd310c69 
---&gt;
# [[/The Delegate's Edition/]]
# [[/Nestorian Steles during the Tang/]] 
&lt;!--- 大秦景教宣元至本經經幢 and 景教碑 ---&gt;
# [[/Hong Xiuquan's Bible/]]
&lt;!--- https://bible.fhl.net/ob/nob.html?book=407 ---&gt;
&lt;!--- I don't want to focus too much on Hong Xiuquan here, so look for more material, especially from missionaries. ---&gt;

===Unit 9: An Introduction to Daoism===
&lt;!--- And now back to your regularly scheduled Zhuangzi/Laozi/Liezi. But with more interesting stuff. Trust! ---&gt;
# [[/Laozi Explains the Dao/]]
# [[/Qingtan with Xie Daoyun/]]
# [[/The Doubting Neighbour/]] 
# [[/Kuafu Chases the Sun/]] 
# [[/The Frog in a Well/]] 
# [[/Wu wei with King Hui of Liang/]]
# [[/The Old Man that Moves the Mountains/]]
# [[/Master Zhuang Dreams of Butterflies/]]
# [[/Master Incapable and the Poisonous Bird/]]
# [[/Transmitting the Dao with Yelü Chucai/]] &lt;!---耶律楚材 - Served 窝阔台, 玄風慶會錄 is short and respectable enough to work with. https://zh.wikisource.org/wiki/%E7%8E%84%E9%A2%A8%E6%85%B6%E6%9C%83%E9%8C%84 ---&gt;
# [[/The Indifferent Taoist/]] &lt;!--- northern song https://zh.wikisource.org/wiki/%E7%8E%89%E6%AD%B7%E5%AF%B6%E9%88%94 ---&gt; 
&lt;!--- Currently very stereotypical, but there's stuff to work with at least. Need to include those weird Daoist characters among other things. ---&gt;

===Unit 10: Nation Focus - Ryukyu Kingdom===
# [[/Historical Annals with Sai On/]] &lt;!--- Kyuko is an easy cop ---&gt;
# [[/The Enthronement of Shō Tei/]] 
# [[/The Twilight of Ryukyu with Shō Ten/]] 
# [[/A Trip to Ryukyu with Luo Sen/]] &lt;!--- Pre-Capstone ---&gt;
&lt;!---
遐邇貫珍 1854-11 - 日本日記 羅森 
https://archive.org/details/HEKC185411/page/n5/mode/1up
A solid description of Ryukyu cultural customs in Volume 11. Absolutely incredible. 
日三日火船直向東北而駛出了臺灣之外幾日不見天涯是時北風大作波浪沖天火船亦甚飄蕩而不能立見有沙鷗隨風而逐浪心直駛七日漸見小山而到琉球琉球一國長闊一百七十五里其國城在地球圖緯線赤道之北二十六度十四分經線中華北京偏東十一度二十四分自明以來世封王爵叨列藩籬其處土產不過蔬菜番薯菜油黑糖等類人民束髻大補是穿草履男女粧飾頭上祇插一簪二簪為別故少年之男女瞥目則無異及其壯也皆留鬚髯故街上長鬚之人甚多甲寅正月初一予上岸遊玩見街上兒童甚多分以銅錢各極歡喜人民亦甚謙恭民居間亦貼新春聯于門外但不見有別等繁華之事那霸有寺寺內有園是名家世宦之墳所以石刊刻姓名年號于碑上每日道人打掃供奉生花樹葉于墓前另有人家祖墳與中國之明塚無異峰巒之上樹木多植民房則以蠻石圍墻內以茅草結屋而居佳物椅棹俱無惟以草蓆屈膝而坐對火盆而吹煙民間亦有識中國言語字墨者
不張舖店惟有墟塲男不貿易婦女為之以貨易貨而外方之金銀弗尚焉然而百姓亦甚畏官長飲食亦甚粗粕甘守樸儉不務奢華亦鮮欺詐板門紙窓夜間亦不防竊曾見途中撿物亦能以返原人公門之內冷冷落落並無案牘之煩淳樸之風畧有同于上古之世我等外國之欲買什物須言于官官為代辦正月初六提督被理衛廉士等一班將官布列威嚴與予乘轎至王宮總理大臣尚宏勳為主席布政大夫馬良才為知客享宴甚豐食物多與中國無異宴後各官皆饋有紙扇烟包布帛等項是物雖粗此亦世子之恭敬外國故亞國亦以禮物而返贈之世子王宮離岸三里在于山頂是名守禮將至其宮一路亦有樹木石牌坊宮室亦甚寬大幽雅垣局可觀其處多栽鳳尾草森樹等類以障陰山邊田土樹藝五穀近海沙田水漲之後人收其沙以煎鹽此時明月當圓予覽山川亦足見一方之風景 
---&gt;
&lt;!--- 中山世鑑 and so on. Lots of poetry too. ---&gt;

===Unit 11: Nation Focus - Singapore===
&lt;!--- National Library of Singapore has a poetry series that's super good! ---&gt;

===Unit 12: Literary Chinese in Medicine===
&lt;!--- do not endorse the medical practices discussed in these...make sure to link back to the heavenly stems here as they are associated with specific body parts. ---&gt;
# [[/The Books of the Yellow Emperor/]] 
&lt;!-- 黃帝内徑 ---&gt;
# [[/Deviant Qi with Zhang Congzheng/]]
&lt;!--- https://zh.wikisource.org/wiki/%E5%84%92%E9%96%80%E4%BA%8B%E8%A6%AA ---&gt;
# [[/Anatomy with Sugita Genpaku/]]
&lt;!--- 解体新書 ---&gt;
# [[/A Lost Wu Medical Text analysed in Japan/]]
&lt;!--- 難經古義 ---&gt;

===Unit 13: People Focus - Zhuang peoples===
&lt;!--- https://mooc1.chaoxing.com/mooc-ans/ztnodedetailcontroller/visitnodedetail?courseId=84745403&amp;knowledgeId=84745463&amp;_from_=&amp;_fromV2_=&amp;rtag= 《峤西诗钞》 is also a really good shout. Found here: https://ctext.org/wiki.pl?if=gb&amp;res=215640&amp;remap=gb ---&gt;
&lt;!--- Basically, there are Zhuang and Tangut peoples who wrote in Literary Chinese, and their inclusion here is to show that even those who made their own scripts would use this tongue. 张鸿翮 imported the character 朴 to describe a bug, for example. ---&gt;
# [[/Zhuang poetry with Li Bi/]]
# [[/The Beauty of Wuyuan with Fang Ju/]]
# [[/Disaster and Society with Wei Fenghua/]]
# [[/Who Deserves a Biography?/]]

&lt;!--- https://wenyi.gmw.cn/2024-06/25/content_37398911.htm

一是忠实记录了汉诗创作与古壮字交融的文化现象。清代壮族诗人张鸿翮（hé）《大塘谣》（《峤西诗钞》卷二）云：

去了休。去到大塘红蓼洲。红蓼生花，不结子。绿朴生花，毬见毬。

诗中所说“绿朴”，是壮族对柚子的惯称。“柚子”，壮语发音为“bug”。根据《古壮字字典》，其对应的古壮字为“朴（㭪）”。诗人将古壮字运用到汉文诗歌创作中，刻下了明清壮汉文化交相辉映的注脚。

This sort of thing is why Zhuang and Tangut inclusion is important, as they show how flexible Literary Chinese can be. ---&gt;

===Unit 14: People Focus - Tangut peoples===
&lt;!--- 羅福萇 and 羅振玉 wrote studies on Western Xia / Tangut script. Look for poets and stuff. ---&gt; 

===Unit 15: Literary Chinese in the Military===
&lt;!--- Real Sun Zi hours! 7 Military Classics are an obvious shout, but look for more stuff too. ---&gt;
# [[/Fū! Rin! Ka! Zan!/]]
# [[/A Bilingual Stele of the Khitans/]]
# [[/Going to war with Boyan/]]
&lt;!---
Boyan's Poem from the 元史
　　伯顏，蒙古巴林部人。至元十一年拜中書左丞相，總兵伐宋。官至開府儀同三司，薨贈太師，封淮安王，諡忠武。

　　《玉堂嘉話》：初，宋未下時，江南謠云：「江南若破，白雁來過。」當時莫喻其意。及宋亡，蓋知指丞相巴延也。

　　過梅嶺岡留題

馬首經從庾嶺回 【 庾嶺回　七修類稿（乾隆刊本）卷四十六作「嶺島歸」。】 ，王師到處悉平夷。擔頭不帶江南物，只插梅花一兩枝。

　　《七修類藳》：伯顏下江南，過金陵梅嶺岡詩云云。所以著名，亦有是善。
---&gt;
# [[/An Edict from the Xianbei/]]
# [[/The Suppression of the Kingdom of Dongning/]]
&lt;!---
台灣鄭氏始末
https://ctext.org/wiki.pl?if=en&amp;chapter=139938

Largely a record of wars in Dongning rather than anything about the trade etc, so it fits here. 
---&gt;
# [[/The Shunzhi Emperor vs Li Zicheng/]]
# [[/The Art of War/]]

===Unit 16: Nation Focus - Vietnam===
# [[/Đỗ Pháp Thuận and the Southern Winds/]]
# [[/Ancestor Veneration with the Descendants of Zhu Xi/]] 
&lt;!--- https://github.com/ShiraTheMogul/fanyahanwen-corpus/tree/main/corpus%2F%E8%B6%8A%E5%8D%97%E6%BC%A2%E6%96%87%2Fclean  somewhere in here ---&gt;
# [[/Resolving a Succession Crisis with Emperor Trần Minh Tông/]] &lt;!-- 南翁夢錄·黎澄 --&gt;
# [[/Spreading Revolutionary Consciousness with Phan Bội Châu and Liang Qichao/]] 
&lt;!--- 越南亡國史 Possibly the most important text in Vietnamese history, not even gonna lie. https://zh.wikisource.org/wiki/%E8%B6%8A%E5%8D%97%E4%BA%A1%E5%9C%8B%E5%8F%B2 ---&gt;
# [[/Academia in Literary Chinese between East and West/]] 
&lt;!--- 南風雜誌 is a massive shout here. Absolutely amazing series. ---&gt;

===Unit 17: Historical Annals and Encyclopediae===
&lt;!--- 永樂大典 will teach how to infer from gaps in texts! 《編類》 is an incredibly interesting essay from here that can bring up the odes and Confucius's「思無邪」quote. It can prepare students for the wrath of Qing academia later. ---&gt; 
# [[/An Introduction to Biographical Paintings/]]
&lt;!-- 
Many older paintings include biographies at the top in Literary Chinese. Students need to learn these.
https://commons.wikimedia.org/wiki/File:%E6%AD%B7%E4%BB%A3%E8%81%96%E8%B3%A2%E5%8D%8A%E8%BA%AB%E5%83%8F_%E5%86%8A_%E8%AB%B8%E8%91%9B%E4%BA%AE_(Zhuge_Liang).png - Famous figure, also part of a very notable series.
https://commons.wikimedia.org/wiki/File:Otomo-Sorin-2.jpg - Contains the Japanese repetition character 々
https://commons.wikimedia.org/wiki/File:Toyotomi_hideyoshi4.jpg - simply has aura
--&gt;
# [[/The History of Liao, Jin, and Song with Toqto'a/]] &lt;!--- 脱脱 ---&gt;
# [[/Two Years in the Forbidden City with Yu Deling/]] &lt;!--- 清宮禁二年記 https://zh.wikisource.org/wiki/%E6%B8%85%E5%AE%AE%E7%A6%81%E4%BA%8C%E5%B9%B4%E8%A8%98 ---&gt;
# [[/Selected Records of the History of the Da Shun/]]
&lt;!--- Fair Use of a 2010 book written in Literary Chinese about the Da Shun dynasty. Limit to 500 characters, if that. Use to encourage recognition of Simplified variants and modern Wenyanwen. ---&gt;
# [[/Documenting the World with Terajima/]]
&lt;!--- 和漢三才図会 寺島良安, built off 三才圖會 ---&gt;

===Unit 18: Buddhist Literature===
&lt;!--- You would be forgiven for wondering why this is so late, but if you look at many classical Buddhist texts you'll quickly see a ton of loanwords that make it significantly more difficult to read than the average text. Thus, it goes here for now. ---&gt;
&lt;!--- Place focus on practical stuff first. Stuff you can and WILL see in Buddhist temples. Stuff Buddhists can take away immediately. Skills-based approach feels strongest here. ---&gt;
&lt;!--- Look at Northern Liang and Later Qin literature, as there is a ton of work by translators from India during the 16 kingdoms period, particularly those two. ---&gt;
&lt;!--- Stuff by Bodhidharma 達摩 could be fun too https://zh.wikisource.org/wiki/Author:%E9%81%94%E6%91%A9 ---&gt;
# [[/Dipping your feet in with Wenyan Shu/]]
&lt;!---
華亭
世尊遺法本忘言，教外別傳意已圓。
只履攜將蔥嶺去，不妨來上月明船。
---&gt; 
# [[/Buddhism in Battle Standards/]]
# [[/The Seven Tathagatas/]] 
&lt;!---
南無寶勝如來
南無多寶如來
南無妙色身如來
南無廣博身如來
南無離怖畏如來
南無甘露王如來
南無阿彌陀佛

Use to introduce some core vocabulary in repetitive manner. 

Useful phrases from my trip to Jing'an Temple
南無本師釋迦牟尼佛 - Pay homage to the root teacher
南無大悲觀世音菩薩 - Pay homage to the goddess of mercy 
廣種福田 - widely plant a meritorious field 
---&gt;
# [[/Two Buddhist Temples in Shanghai/]] 
&lt;!---
留雲禪寺
雲留雲翔領畧幾許禪機此地有雲散天開真如界。
塔內塔外普示無邊圓覺是故曰塔影雙照解脫門。

歲次壬午冬月吉旦。
覺醒敬撰。
楊胡生沐手恭書。
善信印利明敬獻。 
---&gt;
&lt;!--- 福慧宝鼎 慧明大和尚 - introduce the Buddhist timekeeping system with 佛歷 around this point. 
赤烏古剎
建寺一千七百六十周年紀念

古剎三國建
滬瀆有重玄
石佛音淨現
聖跡顯重元
唐時稱永泰
宋敕名靜安
聖祖留佛闡
仲師移伽藍
元收八景偈
明鑄鐘聲梵
清樹化羅漢
選賢十方讚
佛日普光明
福慧共修善
鼎運昌隆際
轉正法輪緣

歲次丁亥住持慧明監製
---&gt;
# [[/Foreseeing Monkhood with Yi Xing/]]
&lt;!--- 看命一掌金 ---&gt;
# [[/A Trip to Western Xia with Zhi Guang and Hui Zhen/]]
&lt;!--- https://zh.wikisource.org/wiki/%E5%AF%86%E5%91%AA%E5%9C%93%E5%9B%A0%E5%BE%80%E7%94%9F%E9%9B%86 ---&gt;
&lt;!--- https://zh.wikisource.org/wiki/%E5%AF%86%E5%92%92%E5%9C%93%E5%9B%A0%E5%BE%80%E7%94%9F%E9%9B%86 ---&gt;
# [[/Jizang's Three Discourses/]]
&lt;!--- https://zh.wikisource.org/wiki/%E4%B8%89%E8%AB%96%E7%8E%84%E7%BE%A9 ---&gt;
&lt;!---
I saw these texts being quoted and thus should consider them in some capacity.
《般若波羅蜜多心經》
《金剛般若波羅蜜經》
《一切智光明仙人慈心因緣不食肉經》
《妙法蓮華經》
《大般涅槃經》
《大方等大集經》
《大毘盧舍那成佛神變加持經蓮華胎藏悲生曼荼羅廣大成就儀軌供養方便會》/ 胎藏曼荼羅 
《佛說救拔焰口餓鬼陀羅尼經》
《雜阿含經》

Look at Japan's 五山文学
---&gt;

===Unit 19: People Focus - Manchu peoples===
# [[/Qing dynasty Poetry with Nara Singde/]] 
&lt;!--- 飲水詞 納蘭性德 https://zh.wikisource.org/wiki/Author:%E7%B4%8D%E8%98%AD%E6%80%A7%E5%BE%B7 ---&gt;
# [[/Amassing Words with the Kangxi Emperor/]] 
# [[/Amassing Literature with the Qianlong Emperor/]] 
&lt;!--- Siku Quanshu abstract https://zh.wikisource.org/wiki/%E5%9B%9B%E5%BA%AB%E5%85%A8%E6%9B%B8%E7%B8%BD%E7%9B%AE%E6%8F%90%E8%A6%81 ---&gt;
&lt;!---
Yongzheng Emperor's Poetry 
https://zh.wikisource.org/wiki/Author:%E9%9B%8D%E6%AD%A3%E5%B8%9D
《和碩怡賢親王祭文》

Also include 滿洲國 stuff to show the fall of the Qing and attempts to preserve it through becoming a Japanese puppet state. It is important to show how Literary Chinese can be misused as well. 滿洲國建國宣言 is a good shout, as is 法制 to prepare students who may be interested in Taiwan legal stuff later down the road. 
https://zh.wikisource.org/wiki/Category:%E6%BB%BF%E6%B4%B2%E5%9C%8B
---&gt;
# [[/Paintings and Beauty with Puru Aisin-Gioro/]]
&lt;!--- Saw these in Shanghai Museum with some writing, seemed really cool. Teaches another skill. ---&gt;

===Unit 20: Qing-RoC Literature===
&lt;!--- many writers here, will be difficult to sift through. Include 四库全書 abstracts and stuff here. ---&gt;
# [[/Jewish Refugees in Shanghai/]] 
&lt;!--- Show passports, certificates, etc, from the Jewish Refugee Museum, anonymised. ---&gt;
# [[/A Literary Chinese Abstract/]] 
&lt;!--- Abstracts from siku quanshu, probably want others ---&gt;
# [[/Lament with Lu Ruoteng/]] 
&lt;!---
《疑猜》盧若騰，東寧國
盟誓變為交質子，春秋戰國風如此；末世上下相疑猜, 更質妻子防逃徙。
此法只可羈庸奴，若遇梟雄術窮矣；妻可再娶子再育, 安能長坐針氈裏。
我贈一法君記存；推心置腹人知恩；眾人畜之眾人報, 幾個國士在君門。
盧若騰撰，陳漢光編輯，《島噫詩》，臺灣文獻叢刊第二四五種（臺北:臺灣銀行經濟研究室，1968年）21頁。
---&gt;
# [[/Common Linguistics Knowledge in the RoC/]]
&lt;!--- 音韻常識 ---&gt;

==References used for this page==
* Yang, B. (2016). 文言语法 [Literary Chinese Grammar] (1st ed). 中华书局 [Zhonghua Book Company]. ISBN: 978-7-101-11619-9
* Priestley, K. E., &amp; Shou-jung, C. (1962). China’s Men of Letters, Yesterday and Today. Dragonfly Books.
{{BookCat}}</text>
      <sha1>pndanv928aq20noultrg79tupultqx9</sha1>
    </revision>
  </page>
  <page>
    <title>Chess Opening Theory/1. e4/1...Nf6/2. e5/2...Nd5/3. c4/3...Nb6/4. a4</title>
    <ns>0</ns>
    <id>484008</id>
    <revision>
      <id>4657158</id>
      <parentid>4655127</parentid>
      <timestamp>2026-08-11T11:46:32Z</timestamp>
      <contributor>
        <username>JCrue</username>
        <id>2226064</id>
      </contributor>
      <origin>4657158</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="872" sha1="490sevsyvc45mukbhefgbqnisqscxs8" xml:space="preserve">{{Chess Opening Theory/Position
|name=Tate variation
|eco=[[Chess/ECOB|B02]]
|parent=[[Chess Opening Theory/1. e4/1...Nf6|Alekhine's defence]] → [[Chess Opening Theory/1. e4/1...Nf6/2. e5/2...Nd5/3. c4|Two pawns attack]] → [[../|3...Nb6]]
}}
== 4. a4!? · Tate variation ==
{{chess/sideline}}
A rare move. 

White's immediate threat is to play a5! and trap Black's knight, so Black needs to either prevent a5 (by playing '''4...a5''' themselves) or give their knight an escape square ('''4...d6''' or '''4...d5'''). 

An idea for White is then to use the a3 square to lift their rook (5. Ra3). 

=== History ===
4. a4 was played by International Master [[w:Emory Tate|Emory Tate]] in 1991.&lt;ref&gt;[https://www.chessgames.com/perl/chessgame?gid=1341122 Tate v Herfel, 1991. Chessgames.com]&lt;/ref&gt;
== References ==
{{reflist}}
===See also ===
{{Chess Opening Theory/Footer}}</text>
      <sha1>490sevsyvc45mukbhefgbqnisqscxs8</sha1>
    </revision>
  </page>
  <page>
    <title>Taiwan history/About Taiwan History</title>
    <ns>0</ns>
    <id>484110</id>
    <revision>
      <id>4657123</id>
      <parentid>4655323</parentid>
      <timestamp>2026-08-11T02:41:56Z</timestamp>
      <contributor>
        <username>Axolitl</username>
        <id>3615435</id>
      </contributor>
      <comment>/* */ Improve lang</comment>
      <origin>4657123</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="837" sha1="m833nv2a61t5vrafjdqe4dvby84k82f" xml:space="preserve">[[file:Taiwan NASA Terra MODIS 23791.jpg|thumb|Taiwan]]
'''Taiwan''' (Traditional Chinese: {{lang|zh|台灣}}) is an island located on the Pacific Ocean, a country with a complex history. It is a rich mosaic shaped by its indigenous roots, successive waves of colonization, and a modern transformation into a thriving democracy and global technological powerhouse. Learning the Taiwan history can help you understand more about the Taiwanese culture. This book will introduce all of the Taiwanese history, from the Prehistorical Era to the Modern day Taiwan. Have fun learning!

'''Note:''' Not to be confused with ''[[History of Republic of China]]'', which is the modern government in Taiwan, started in 1912 in mainland China, and retreated to Taiwan in 1949. This book will be focusing on the island of Taiwan's history.

{{BookCat}}</text>
      <sha1>m833nv2a61t5vrafjdqe4dvby84k82f</sha1>
    </revision>
  </page>
  <page>
    <title>Statistics for Sociologists/Chapter 1: Why Statistics? Making Sense of Social Life with Data</title>
    <ns>0</ns>
    <id>485135</id>
    <revision>
      <id>4657120</id>
      <parentid>4656713</parentid>
      <timestamp>2026-08-11T01:00:51Z</timestamp>
      <contributor>
        <username>JackBot</username>
        <id>396820</id>
      </contributor>
      <minor />
      <comment>Formatting, [[Special:UncategorizedPages]]</comment>
      <origin>4657120</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="17265" sha1="2pbsv4knd2jfi0z39if0368wbgmgovl" xml:space="preserve">= Chapter 1: Why Statistics? Making Sense of Social Life with Data =

Ask a room full of sociology students why they're taking a statistics course, and you will get some version of the same three answers: it's required, they heard it's &quot;not that bad,&quot; and they are visibly regretting their choice of major. This chapter exists to argue, gently but persistently, that all three of those students are wrong about at least one thing. Statistics is not just a hoop you have to jump through. It is one of the more interesting tools ever built for answering a question sociology cares about more than almost any other discipline: what is actually going on with people, as opposed to what we assume is going on with people.

That distinction — between what's actually going on and what we assume is going on — is the entire subject of this book.
[[File:Group of people, Novosibirsk 1.jpg|alt=A group of people in a park.|thumb|600x600px|There is a lot going on within any group of people. Statistics are used in Sociology to study groups of people.]]

== What Statistics Is (and What It Isn't) ==

Statistics is not magic. It will not tell you what people ''should'' do, whether capitalism is good, or why your cousin holds the political views he holds. It cannot generate a fact from nothing, and it cannot rescue a badly designed study. Statistics is, more modestly, a set of tools for describing patterns in data and for deciding how much confidence those patterns deserve.

It is also not &quot;just arithmetic,&quot; despite what the equation-heavy chapters later in this book might suggest to a skeptical reader flipping ahead. Arithmetic tells you that 2 + 2 = 4. Statistics tells you whether the four-point gap in reported happiness between two groups of people is a real social pattern worth taking seriously, or the kind of noise you'd expect to see even if nothing were going on at all. That second question — is this real, and does it matter — is a much more interesting question than any of the arithmetic required to answer it, and it is the question this entire book is organized around. (If statistics really were just arithmetic, this book would be four pages long, and one of those pages would be a lecture on the order of operations.)

Here is a useful mental model: statistics is what you get when you refuse to trust your gut about how the social world works until you've checked.

== Anecdote vs. Evidence ==

Humans are excellent at building confident, coherent stories out of very small amounts of information. This was probably a useful skill on the savanna. It is a much less useful skill for understanding society, because society does not fit inside any one person's field of view.

Consider a genuinely humbling body of research on how badly people estimate basic facts about their own societies. Survey researchers have repeatedly asked people in wealthy democracies to guess things like the percentage of the population that is Muslim, the percentage of teenagers who become pregnant each year, or the share of national wealth held by the top 1%. The results are not close. People in the United States, for instance, have historically guessed the Muslim share of the population at somewhere around 15%; the actual figure is about 1%.&lt;ref&gt;Ipsos MORI, &quot;Perils of Perception&quot; surveys, various years.&lt;/ref&gt; This is not a small rounding error. This is being off by a factor of fifteen while feeling completely confident about it.
[[File:Perception vs Reality - Statistics for Sociology Chart.png|alt=A dumbbell chart showing perceptions and reality.|center|thumb|800x800px|A chart illustrating the difference between perceptions of social facts and the reality of social facts.]]

The point is not that people are stupid (well... that's mostly not the point!). The point is that human intuition about large-scale social patterns is built from whatever we happen to have personally encountered — the news we watch, the neighborhood we live in, the one loud cousin at Thanksgiving — and none of that adds up to a representative picture of anything. Anecdote feels like evidence. It is not evidence. It is a sample size of one, dressed up in a confident tone of voice. Your uncle at Thanksgiving may be extremely confident about what &quot;everyone&quot; thinks; he is, statistically speaking, an n of one, and no peer-reviewed journal on Earth will publish him, no matter how loudly he clears his throat before the next point.

Statistics exists because &quot;I feel like this is true&quot; and &quot;this is true&quot; are different claims, and sociology needs a way to tell them apart.

== What Sociology Needs Statistics For ==

Sociologists use statistics for a handful of related but distinct jobs:

* '''Describing populations.''' How many people hold a given belief? What does the income distribution actually look like? Description sounds boring until you realize almost no one's intuitive guess about these numbers is correct.
* '''Testing hypotheses.''' Does education predict income? Does religious attendance predict happiness? Sociological theory generates predictions; statistics is how those predictions get checked against reality instead of just sounding plausible in a seminar room.
* '''Identifying patterns.''' Social life is full of relationships between variables that are invisible at the individual level and only show up once you look at enough people at once — this is arguably the founding insight of the entire discipline, going back to Durkheim noticing that suicide, an intensely personal act, follows remarkably stable social patterns.&lt;ref&gt;Durkheim, É. (1951). ''Suicide: A Study in Sociology'' (J. A. Spaulding &amp; G. Simpson, Trans.). Free Press. (Original work ''Le Suicide: Étude de sociologie'' published 1897)&lt;/ref&gt; Sociologists have, in other words, been doing data science since roughly 1897; we just didn't have nifty computers to help with the analyses back then, not even human [[wikipedia:Computer_(occupation)|computers]].
* '''Informing policy.''' Governments and organizations make decisions that affect millions of people based on what the data seem to show. Getting the statistics wrong has consequences that extend well past a bad grade on a problem set.

Throughout this book, you will do all four of these things using the [[Statistics for Sociologists/Chapter 3: The General Social Survey - What It Is and How to Use It|General Social Survey]], a dataset that includes responses from surveys asking Americans about their lives, beliefs, and behaviors since 1972. You'll meet it properly in Chapter 3. For now, just know that everything from here forward is aimed at letting you ask real questions about real people and get real answers — not perfect answers, but honest ones, with the uncertainty attached.

== A Field That Occasionally Embarrasses Itself: The Replication Crisis ==

Here is where this book earns some credibility by admitting something uncomfortable: a fair amount of what gets published across the social and behavioral sciences — sociology fully included, not just the neighbors down the hall in the psychology department — does not hold up when someone else checks it.

Starting around 2011, researchers began systematically trying to replicate published findings — that is, running the same study again, often with fresh data and more statistical power, to see if it produced the same result. The first wave of this work focused on psychology: a large-scale effort by the [http://osc.centerforopenscience.org/ Open Science Collaboration] attempted to replicate 100 studies from top psychology journals, and fewer than half succeeded.&lt;ref&gt;Open Science Collaboration, &quot;Estimating the Reproducibility of Psychological Science,&quot; ''Science'', 2015.&lt;/ref&gt; For years afterward, &quot;the replication crisis&quot; got treated in casual conversation as psychology's problem to solve, which let everyone else in the social sciences feel a little smug about it.

That smugness became harder to justify in 2026. A massive replication effort — the DARPA-funded SCORE project — attempted to replicate 274 specific findings drawn from 164 papers published between 2009 and 2018, across six fields: business, economics, education, political science, psychology, ''and sociology''.&lt;ref&gt;Tyner, A. H. et al. &quot;Investigating the replicability of the social and behavioural sciences.&quot; ''Nature'' 652, 143–150 (2026).&lt;/ref&gt; The replications were not casual efforts, either — they were high-powered (median 99.6% power to detect the original effect), used the original study materials when available, and were peer-reviewed in advance. This was about as fair a test as a field can get.
[[File:Bar Chart Illustrating Replication Rates in Social Science Disciplines.png|alt=A bar chart illustrating replication rates.|none|thumb|800x800px|This chart, created in R, illustrates the replication rates in the social sciences per Tyner et al. 2026.]]

The results, by discipline, were remarkably consistent — consistently unflattering. Across all six fields, only about half of claims held up: 55.1% of individual claims and 49.3% of papers replicated with a statistically significant result in the original direction. Sociology's rate was 51.1% — essentially indistinguishable from psychology's 49.0%, and statistically no different from any other field in the study (the range across disciplines ran from 42.5% to 63.1%, and the differences between fields were not significant). In plainer terms: if you flip a coin to decide whether a published sociology finding will replicate, you will do about as well as the field's actual track record — which is not a compliment, but it is at least an ''equitable'' embarrassment, evenly distributed across the disciplines that study people.

It gets more specific, and slightly worse. Among the sociology studies where an effect size (more on these in later chapters) could be directly compared, the original published effect was already fairly modest (median Pearson's ''r'' = 0.10) — smaller, on average, than the original effects reported in business, economics, or psychology. When those same claims were replicated, the median effect size shrank further, to ''r'' = 0.03. That is not quite zero. It is, however, close enough to see zero from where it's standing.

None of this happened because researchers were, as a rule, committing fraud. It happened because of a set of ordinary, human, entirely predictable practices that this book will spend real time on:

[[File:Miso Soup.jpg|alt=a bowl of soup|thumb|400x400px|One famous study that failed to replicate was from the lab of now largely discredited researcher [[wikipedia:Brian_Wansink#Retractions_and_corrections|Brian Wansink]], claiming that people ate more if they were given a bowl of soup that had more soup pumped in from the bottom. Much of Wansink's work was later retracted because the underlying data were manipulated in ways this course will teach you are unethical.]]

* '''Small samples''' that produce noisy, unstable results that happen to look like a pattern.
* '''[[wikipedia:Data_dredging|p-hacking]]''' — trying several analyses and reporting only the one that &quot;worked&quot; (more on this in Chapter 18, where it gets a proper dissection).
* '''[[wikipedia:Publication_bias|Publication bias]]''' — journals overwhelmingly publish studies that find something, so the file drawer fills up with the honest null results nobody ever sees. (The file drawer, it turns out, is a lot roomier than anyone likes to admit — sociology has been contributing to it right alongside everyone else.)
* '''No data or code sharing''', which meant that for decades, nobody could even check anyone else's work without redoing the entire study from scratch.

So: this is not a chapter about psychology's problem. It is a chapter about sociology's problem, documented as recently as 2026, with your discipline's name attached to the data in black and white. The GSS-based examples in this book will use real sample sizes and real reported effects specifically so you get comfortable with what honest, adequately powered social science looks like — which, encouragingly, is not that hard to produce once you know what to watch for, and which is exactly what the rest of this book is trying to teach you to do.

== Open Science: The Field Grows Up ==
[[File:OSF.png|alt=A screenshot of the OSF.io website.|thumb|600x600px|This is the home page for the OSF, which is run by the Center for Open Science. You'll have plenty of chances to work with the website throughout this course.]]

The response to the replication crisis has been a genuine culture shift, usually filed under the heading [[wikipedia:Open_science|'''open science''':]] the practice of doing research in a way that lets other people check it. In practice this means a few concrete habits, all of which you will build over the course of this book:

* '''Transparency''' about what you did — including the analyses that didn't pan out.
* '''Data sharing''', so other researchers can look at what you looked at.
* '''Code sharing''', so other researchers can run what you ran, rather than guessing at your methods from a paragraph in a journal article.
* '''Pre-registration''', which means writing down your hypothesis and analysis plan ''before'' you look at the results — the statistical equivalent of calling your shot.

A tool that has become central to this shift is the '''Open Science Framework''' (OSF), a free platform where researchers post their data, code, and pre-registrations. Think of it as a public diary for your research — except instead of embarrassing teenage feelings, it holds your regression code, which, depending on how that regression turned out, might be the more embarrassing of the two. You'll set up your own OSF project in Chapter 2, and you'll see &quot;Open Science Corner&quot; boxes like this one scattered through the rest of the book:

{{Colored box
| title = Open Science Corner
| background-title-color=#355C7D
| title-color=#FFFFFF
| background-content-color=#F8B195
| content = Sharing your code and data is not an act of vulnerability, and it is not something you do only after you've become an established researcher with tenure and nothing left to prove. It is a basic professional habit, on the same level as citing your sources — and after the last decade, the field has run out of excuses not to do it.
}}

None of this is presented here as mandatory virtue. It's presented as what careful researchers already do, because the alternative — as an entire replication crisis demonstrated — is occasionally embarrassing itself in front of the entire discipline.

== Chapter Summary ==

Statistics is a set of tools for figuring out whether a pattern you think you see in social life is actually there, and if it is, whether it's big enough to matter. Human intuition is bad at this job on its own — we build confident stories out of tiny, unrepresentative samples of our own experience, and those stories routinely turn out to be wrong when checked against actual data. Sociology relies on statistics to describe populations, test theories, find patterns invisible at the individual level, and inform decisions that affect real people. The field has recently had to reckon with a replication crisis — and a 2026 large-scale replication effort confirmed that sociology's published findings hold up about as often as psychology's, roughly half the time, with effect sizes that often shrink close to nothing on a second look. This is not one field's embarrassment; it is a shared one, caused by small samples, selective reporting, and a lack of transparency across the social sciences. The discipline-wide response, open science, is less a set of rules than a professional habit of showing your work. This book will build that habit alongside every statistical skill in it.

== Think About It ==

This chapter has no R code and no practice problems — just some things worth sitting with before Chapter 2 gets you into RStudio.

# Think of a belief you hold about some group of people (a generation, a political party, a profession — anything) that is based mostly on personal experience or things you've seen online rather than on any data you've actually looked at. What would it take to check whether that belief holds up? What data would you need?
# The chapter argues that anecdotes &quot;feel like evidence.&quot; Why do you think vivid individual stories are so much more persuasive to most people than a table of statistics showing the same pattern across thousands of cases? Is this a flaw we should try to correct, or does it serve some purpose?
# If a well-known, widely cited finding in your field of interest turned out to fail replication tomorrow, what do you think the honest response should be — from the original researcher, from the field, and from the public that had heard about the finding? Does it matter whether the original researcher did anything wrong?

&lt;!-- FIGURE: Optional second figure — bar chart of replication rates by discipline from Tyner et al. (2026), Table 3, highlighting that sociology (51.1%) and psychology (49.0%) are statistically indistinguishable. Author to generate if desired; data available in the source PDF. --&gt;

== References ==
&lt;references/&gt;

{{BookCat}}</text>
      <sha1>2pbsv4knd2jfi0z39if0368wbgmgovl</sha1>
    </revision>
  </page>
  <page>
    <title>Statistics for Sociologists/Chapter 2: Getting Started with R and RStudio</title>
    <ns>0</ns>
    <id>485136</id>
    <revision>
      <id>4657121</id>
      <parentid>4656585</parentid>
      <timestamp>2026-08-11T01:00:52Z</timestamp>
      <contributor>
        <username>JackBot</username>
        <id>396820</id>
      </contributor>
      <minor />
      <comment>Formatting, [[Special:UncategorizedPages]]</comment>
      <origin>4657121</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="19585" sha1="lsalf5il513eppgmzmabekt5xyxr44r" xml:space="preserve">= Chapter 2: Getting Started with R and RStudio =

Every statistics course eventually arrives at an awkward moment: before you can analyze anything, you have to install something. This chapter is that moment. It is not glamorous, and approximately no one has ever described installing software as &quot;fun,&quot; but it is a one-time cost, and by the end of this chapter you will have a working statistical environment on your computer and the first few sentences of a new language under your belt.

That language is R. This chapter gets you talking to it.

&lt;!-- IMAGE: A friendly, low-stakes illustration of a laptop with the R and RStudio logos, or a photo of a clean, uncluttered RStudio desktop setup — something to make the &quot;installation chapter&quot; feel approachable rather than intimidating. --&gt;

== What Is R? What Is RStudio? ==

'''R'''&lt;ref&gt;R Core Team. ''R: A Language and Environment for Statistical Computing''. R Foundation for Statistical Computing, Vienna, Austria. https://www.R-project.org/&lt;/ref&gt; is a programming language built specifically for statistics. It is free, it is open source, and it is what a very large share of working statisticians, data scientists, and quantitative social scientists actually use — not because it's trendy, but because it does what it's built to do, and thousands of people have spent decades adding to it. This is not Excel with a promotion. Excel is built for accounting and calendars, and it shows the strain the moment you ask it to do anything statistically serious. R was built for exactly this job, from the ground up.

'''RStudio''' is not a different thing from R — it's a way of using R that doesn't make you want to throw your laptop out a window. R by itself is just an engine: it runs, it does the math, but it gives you almost nothing to look at while it works. RStudio is the car built around that engine — the dashboard, the windows, the seats, the place where you actually sit while the engine does its job. You will install both. You will only ever open one.

== Installing R and RStudio ==

Installation instructions for software change more often than a textbook can keep up with, so rather than walk through exact button-clicking steps that may be outdated by the time you read this, here is the durable version:

# Go to the '''CRAN''' website (the Comprehensive R Archive Network, at cran.r-project.org) and download R for your operating system. This installs the engine.
# Go to '''Posit''' (posit.co, the company that makes RStudio — formerly called RStudio, in a naming decision that has confused exactly everyone) and download RStudio Desktop, the free version. This installs the dashboard.
# Install R first, then RStudio. Order matters here the way it matters for putting on socks before shoes.
# Open RStudio, not R directly. If everything installed correctly, RStudio will find R automatically and you'll never need to open R by itself again.

If your first attempt at installing anything statistical software-related feels slightly wrong — like you're not sure you did it correctly even after it seems to have worked — that is a completely normal reaction and not a sign you are bad at this. Everyone in this field has had that exact feeling at least once. Most have had it more than once, usually right before an update.

&lt;!-- IMAGE: Simple side-by-side visual of the CRAN download page and the Posit/RStudio download page, or a labeled diagram showing &quot;Step 1: Install R&quot; → &quot;Step 2: Install RStudio&quot; → &quot;Step 3: Open RStudio.&quot; Helps orient students who are installing for the first time. --&gt;

== A Tour of RStudio ==

When you open RStudio for the first time, you'll see it divided into several panes. Don't panic — you will not need to master all of them today.

* '''Console.''' The bottom-left pane (or sometimes the whole left side). This is where you type commands directly and R responds immediately. Think of it as a conversation with R that nobody saves unless you tell it to.
* '''Script Editor.''' The top-left pane, which appears once you open or create a script file (a plain text file ending in &lt;code&gt;.R&lt;/code&gt;). This is where you write code you intend to keep, run, and rerun — as opposed to the Console, which forgets everything the moment you close it.
* '''Environment pane.''' Usually top-right. Lists every object you've created in your current session — every vector, every data frame, every variable name you've typed into existence. This is your workspace's inventory.
* '''Files / Plots / Help pane.''' Usually bottom-right. A multitasking corner: it shows your file browser, displays any plots you generate, and hosts R's built-in help documentation (accessible any time by typing &lt;code&gt;?functionname&lt;/code&gt; in the Console — a habit worth building early, since Googling &quot;R table function&quot; tends to return furniture before it returns documentation).

The single most important habit to build right now: '''write your code in the Script Editor, not the Console.''' The Console is for quick questions you'll never need again — &quot;what's 47 times 12&quot; territory. Anything you might want to run again tomorrow, or hand in for an assignment, or show your professor when something breaks, belongs in a script.

&lt;!-- IMAGE: An annotated screenshot of the RStudio interface with the four panes labeled (Console, Script Editor, Environment, Files/Plots/Help). This is the single most useful image this chapter could have — students benefit enormously from seeing the real layout with labels, not just reading about it. --&gt;

== Basic R: Arithmetic, Assignment, and Running Code ==

R will do arithmetic the moment you ask it to. Type this into the Console and press Enter:

&lt;syntaxhighlight lang=&quot;r&quot;&gt;
2 + 2
&lt;/syntaxhighlight&gt;

R will respond with &lt;code&gt;[1] 4&lt;/code&gt;. The &lt;code&gt;[1]&lt;/code&gt; is not R being weird for its own sake — it's telling you that this is the first (and in this case only) value in the result. You'll understand why that matters once results start having more than one value, which will be almost immediately.

R also does subtraction, multiplication (&lt;code&gt;*&lt;/code&gt;), division (&lt;code&gt;/&lt;/code&gt;), and exponents (&lt;code&gt;^&lt;/code&gt;), in the standard order of operations. Try:

&lt;syntaxhighlight lang=&quot;r&quot;&gt;
(5 + 3) * 2
10 / 4
2^3
&lt;/syntaxhighlight&gt;

The more important operator, and the one that will confuse you for approximately one week and then never again, is '''assignment''': &lt;code&gt;&lt;-&lt;/code&gt;. This stores a value under a name you choose.

&lt;syntaxhighlight lang=&quot;r&quot;&gt;
x &lt;- 5
x
&lt;/syntaxhighlight&gt;

Read &lt;code&gt;&lt;-&lt;/code&gt; out loud as &quot;gets.&quot; &quot;&lt;code&gt;x&lt;/code&gt; gets 5&quot; means: take the value 5, and store it in an object called &lt;code&gt;x&lt;/code&gt;. From now on, typing &lt;code&gt;x&lt;/code&gt; will return 5, until you assign something else to it. The arrow points in the direction the value is flowing — from the 5 into the &lt;code&gt;x&lt;/code&gt; — which is either a small, elegant piece of interface design or the closest thing R has to a philosophical statement, depending on how much sleep you've had.

(You can also use &lt;code&gt;=&lt;/code&gt; for assignment in most contexts, and you will see it in other people's code. This book uses &lt;code&gt;&lt;-&lt;/code&gt; throughout, both because it's the R convention and because it makes the direction of &quot;what is being stored where&quot; unambiguous.)

== Objects You'll Meet: Vectors and Data Frames ==

You don't need a full computer science vocabulary to use R, but two object types will show up constantly from Chapter 5 onward, so it's worth meeting them now, briefly, like introducing two people you'll be spending the semester with.

A '''vector''' is a sequence of values of the same type — all numbers, or all text, but not mixed. You build one with the &lt;code&gt;c()&lt;/code&gt; function (short for &quot;combine&quot;):

&lt;syntaxhighlight lang=&quot;r&quot;&gt;
ages &lt;- c(24, 31, 45, 19, 62)
ages
&lt;/syntaxhighlight&gt;

A '''data frame''' is what you'll spend most of this book working with: a rectangular table, rows and columns, exactly like a spreadsheet, where each column is typically a vector and each row is typically a case — in this book's terms, a GSS respondent. You won't build data frames from scratch very often; you'll load them from files, starting in Chapter 3. For now, just know the shape: rows are people, columns are variables, and the whole thing is called a data frame.

== Packages: Teaching R New Tricks ==

R comes with a lot built in, but the real power comes from '''packages''' — bundles of additional functions that other people have written and shared, freely, for exactly this purpose. You install a package once per computer, and load it once per R session.

&lt;syntaxhighlight lang=&quot;r&quot;&gt;
install.packages(&quot;tidyverse&quot;)
library(tidyverse)
&lt;/syntaxhighlight&gt;

The '''tidyverse'''&lt;ref&gt;Wickham, H., Averick, M., Bryan, J., Chang, W., McGowan, L. D., François, R., Grolemund, G., Hayes, A., Henry, L., Hester, J., Kuhn, M., Pedersen, T. L., Miller, E., Bache, S. M., Müller, K., Ooms, J., Robinson, D., Seidel, D. P., Spinu, V., Takahashi, K., Vaughan, D., Wilke, C., Woo, K., &amp; Yutani, H. (2019). Welcome to the tidyverse. ''Journal of Open Source Software'', 4(43), 1686.&lt;/ref&gt; is a collection of packages (including &lt;code&gt;dplyr&lt;/code&gt;, which you'll use constantly, and &lt;code&gt;ggplot2&lt;/code&gt;, which you'll meet in Chapter 7) designed to work together and, not coincidentally, designed to be more readable than base R for a lot of everyday data tasks. This is why this book teaches both base R and tidyverse/dplyr approaches side by side throughout: base R is the foundation every R user should understand, and dplyr is often the faster, more legible way to write the same operation once you know what's happening underneath it. Neither one is the &quot;right&quot; answer. They're two dialects of the same language, and fluent R users can generally read both even if they mostly write one.

You'll want one more package now, even though you won't use it until Chapter 3: '''haven'''&lt;ref&gt;Wickham, H., Miller, E., &amp; Smith, D. ''haven: Import and Export 'SPSS', 'Stata' and 'SAS' Files''. R package. https://haven.tidyverse.org&lt;/ref&gt;, which reads data files saved in other statistical programs' native formats — including the &lt;code&gt;.sav&lt;/code&gt; format used by SPSS, which is how you'll actually receive the GSS data for this course.

&lt;syntaxhighlight lang=&quot;r&quot;&gt;
install.packages(&quot;haven&quot;)
library(haven)
&lt;/syntaxhighlight&gt;

Why does a file format from a completely different program matter in an R course? Because a &lt;code&gt;.sav&lt;/code&gt; file carries more than raw numbers — it carries the codebook's value labels and missing-value definitions baked directly into the file. Load it with the right tool, and R already knows, before you've written a single line of cleanup code, that a response of &quot;8&quot; means &quot;don't know.&quot; You'll see exactly what that buys you starting in Chapter 3.

When you run &lt;code&gt;library(tidyverse)&lt;/code&gt; for the first time, R will print a small wall of text about &quot;conflicts&quot; and &quot;attaching packages.&quot; This looks like an error. It is not an error. It is R being unusually polite and telling you exactly what it just did. Read it once, feel briefly reassured, and move on.

== Writing and Saving Scripts ==

A script is a plain text file, saved with a &lt;code&gt;.R&lt;/code&gt; extension, containing the code you want to keep. Build the habit now of doing your work in a script rather than typing directly into the Console: click File → New File → R Script, write your code there, and run lines or selections with Ctrl+Enter (Cmd+Return on a Mac).

Save your script early and often, and save it somewhere you'll remember — ideally a dedicated folder for this course. Future you, three weeks from now, trying to remember which file had the working version of an assignment, will thank present you for this one small habit more than for almost anything else in this chapter.

== Setting Up an OSF Project ==

You met the Open Science Framework conceptually in Chapter 1. Here's the practical version: go to osf.io, create a free account, and start a new project for this course. Give it an honest, findable name — &quot;STATS 201 Coursework,&quot; not &quot;final_FINAL_v3.&quot; Inside that project, you'll eventually upload the R scripts you write for each assignment.

{{Colored box
| title = Open Science Corner
| background-title-color=#355C7D
| title-color=#FFFFFF
| background-content-color=#F8B195
| content = Why bother setting this up for a class project nobody outside this course will ever see? Because the habit is the point, not the audience. Professional researchers don't reserve good data practices for the papers they expect to become famous — they build the habit early enough that it's automatic by the time it matters. You're building that habit now, on assignments with low stakes, so it's already second nature when the stakes are higher.
}}

&lt;!-- IMAGE: A screenshot of the OSF &quot;Create new project&quot; page, to walk students through the actual interface they'll see. Low priority but genuinely useful for a first-time setup task. --&gt;

== A Note on R Markdown ==

At some point — not necessarily in this course, but soon — you'll want to combine your R code, your results, and your written interpretation into a single document instead of juggling a script and a Word document separately. The tool for this is '''R Markdown''', which lets you write text and code in the same file and produce a polished report (PDF, Word, or HTML) with a single click. This book won't require it, but it's worth knowing it exists: think of it as the next level once base R starts feeling comfortable, and a very good habit for anyone heading toward a senior thesis, a capstone project (see Chapter 18), or a career that involves explaining data to other humans.

== Base R and dplyr: Two Dialects, One Language ==

You'll notice that starting in the next few chapters, this book routinely shows you two ways to do the same thing: a base R version and a dplyr version. This is deliberate, not redundant. Base R is the language's native grammar — it doesn't require any packages, it's what you'll find in decades of existing R code and Stack Overflow answers, and understanding it makes you far less helpless when something goes wrong. dplyr, part of the tidyverse, is a more recent dialect built around a small set of readable verbs (&lt;code&gt;filter()&lt;/code&gt;, &lt;code&gt;select()&lt;/code&gt;, &lt;code&gt;mutate()&lt;/code&gt;, &lt;code&gt;summarize()&lt;/code&gt;) that often make your intentions clearer at a glance.

Learning both is like learning a language's formal grammar and its everyday slang at the same time. You'll come to prefer one for most everyday work — most people eventually lean dplyr — but you'll be able to read the other one when you encounter it, which, in an R user's life, is often.

== Chapter Summary ==

R is a free, powerful programming language built for statistics; RStudio is the interface that makes R usable day to day. After installing both, you'll do your work in a script (not the Console), using &lt;code&gt;&lt;-&lt;/code&gt; to assign values to named objects, and &lt;code&gt;install.packages()&lt;/code&gt; plus &lt;code&gt;library()&lt;/code&gt; to add new capabilities via packages like the tidyverse and haven. Vectors and data frames are the two object types you'll meet constantly going forward — data frames especially, since that's the shape GSS data will take starting in Chapter 3, whether you load it from a &lt;code&gt;.csv&lt;/code&gt; file or, as this course does, a &lt;code&gt;.sav&lt;/code&gt; file via haven. You've also set up an OSF project, established the habit of scripting your work rather than doing it by hand, and gotten a preview of R Markdown as the natural next step once this all feels less new. Every chapter from here forward will show you both base R and dplyr approaches to the same problems — two dialects of one language, both worth understanding.

== Practice Examples ==

=== Example 1: Install, Run, Celebrate ===

'''The Task:''' Install R and RStudio following the steps above. Open RStudio and confirm it's working.

'''The Code:'''
&lt;syntaxhighlight lang=&quot;r&quot;&gt;
2 + 2
&lt;/syntaxhighlight&gt;

'''The Output:'''
&lt;syntaxhighlight lang=&quot;r&quot;&gt;
[1] 4
&lt;/syntaxhighlight&gt;

'''The Interpretation:''' If you see &lt;code&gt;[1] 4&lt;/code&gt;, R and RStudio are correctly installed and communicating with each other. This is a low bar, and you should clear it with a small sense of triumph anyway. Every statistical analysis in this book, no matter how sophisticated it eventually gets, rests on this exact same infrastructure working correctly.

'''Follow-Up Challenge:''' Try a few more calculations of your own — including at least one using &lt;code&gt;^&lt;/code&gt; for exponents and one using parentheses to control order of operations. Confirm the results match what you'd expect by hand.

=== Example 2: Installing the Tidyverse ===

'''The Task:''' Install and load the tidyverse package, and get comfortable with what its startup message is telling you.

'''The Code:'''
&lt;syntaxhighlight lang=&quot;r&quot;&gt;
install.packages(&quot;tidyverse&quot;)
library(tidyverse)
&lt;/syntaxhighlight&gt;

'''The Output:''' Installation will print a fair amount of scrolling text as R downloads several packages. Loading the library will print something like:
&lt;syntaxhighlight lang=&quot;r&quot;&gt;
-- Attaching core tidyverse packages ------------------------ tidyverse 2.0.0 --
v dplyr     1.1.4     v readr     2.1.5
v forcats   1.0.0     v stringr   1.5.1
v ggplot2   3.5.1     v tibble    3.2.1
v lubridate 1.9.3     v tidyr     1.3.1
v purrr     1.0.2
-- Conflicts ---------------------------------------------- tidyverse_conflicts() --
x dplyr::filter() masks stats::filter()
x dplyr::lag()    masks stats::lag()
i Use the conflicted package to force all conflicts to become errors
&lt;/syntaxhighlight&gt;

'''The Interpretation:''' This is not an error message. It's a packing list: R is telling you exactly which packages it just loaded and which of their functions overlap with functions already built into base R (the &quot;conflicts&quot; section). In practice, this rarely causes problems, and you can proceed as soon as you see it. The instinct to panic at a wall of console text is one you'll want to unlearn early, because R produces a lot of informational text that looks scarier than it is.

'''Follow-Up Challenge:''' Run &lt;code&gt;library(tidyverse)&lt;/code&gt; a second time in the same session. Notice that it loads instantly with no startup message. Why do you think that is?

=== Example 3: Your First Useful Calculation ===

'''The Task:''' Create a vector and compute something about it — your first taste of R doing actual statistical work, however small.

'''The Code (base R):'''
&lt;syntaxhighlight lang=&quot;r&quot;&gt;
ages &lt;- c(24, 31, 45, 19, 62)
mean(ages)
&lt;/syntaxhighlight&gt;

'''The Code (dplyr equivalent, for a vector wrapped in a data frame):'''
&lt;syntaxhighlight lang=&quot;r&quot;&gt;
library(dplyr)
tibble(ages = c(24, 31, 45, 19, 62)) %&gt;%
  summarize(mean_age = mean(ages))
&lt;/syntaxhighlight&gt;

'''The Output:'''
&lt;syntaxhighlight lang=&quot;r&quot;&gt;
[1] 36.2
&lt;/syntaxhighlight&gt;

'''The Interpretation:''' The average of these five ages is 36.2 years. This is, admittedly, not a sociological finding of great consequence — but it is the same operation, structurally, that you'll be performing on thousands of real GSS respondents by Chapter 8. The mechanics don't change; only the size and meaningfulness of the data does.

'''Follow-Up Challenge:''' Add a sixth age to the vector and recompute the mean by hand before running the code again. Does R's answer match yours? If your data represented real respondents, what else would you want to know about this group before drawing any conclusions from a single average?

== References ==
&lt;references/&gt;

{{BookCat}}</text>
      <sha1>lsalf5il513eppgmzmabekt5xyxr44r</sha1>
    </revision>
  </page>
  <page>
    <title>Wikibooks:Reading room/Archives/2026/June</title>
    <ns>4</ns>
    <id>485185</id>
    <revision>
      <id>4657142</id>
      <parentid>4656735</parentid>
      <timestamp>2026-08-11T08:10:18Z</timestamp>
      <contributor>
        <username>ArchiverBot</username>
        <id>1227662</id>
      </contributor>
      <minor />
      <comment>Bot: Archiving 2 threads from [[Wikibooks:Reading room/Technical Assistance]]</comment>
      <origin>4657142</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2110" sha1="sxy6ypsselca8qugdnstve487fljkh4" xml:space="preserve">{{talk archive}}

== Template:Printable testing ==

Is there any way to use Template:Printable so that it creates a printable version of a ''different'' page? I've been wanting to see what it looks like without having to create a subpage. &lt;span style=&quot;color:#FF0000&quot;&gt;[[User:User97104|User]]&lt;/span&gt;&lt;span style=&quot;color:#FF0000&quot;&gt;[[User talk:User97104|97104]] &lt;/span&gt;&lt;span style=&quot;color:#FF0000&quot;&gt;[[Special:Contributions/User97104|(fixes)]]&lt;/span&gt; 23:59, 8 June 2026 (UTC)
== A location in a page. ==

Hi,&lt;br&gt;
A location in a page can be specified with empty span such as &lt;nowiki&gt;&lt;span id=&quot;location&quot;&gt;&lt;/span&gt;&lt;/nowiki&gt;, although not tidy. Can someone suggest another possibility or two, please?&lt;br&gt;
Thanks, ... [[User:PeterEasthope|PeterEasthope]] ([[User talk:PeterEasthope|discuss]] • [[Special:Contributions/PeterEasthope|contribs]]) 13:22, 14 June 2026 (UTC)

:: ... &lt;a id=&quot;location&quot;&gt;&lt;/a&gt; is a little more compact than span. Thx, ... [[User:PeterEasthope|PeterEasthope]] ([[User talk:PeterEasthope|discuss]] • [[Special:Contributions/PeterEasthope|contribs]]) 01:56, 20 June 2026 (UTC)
::: &lt;a doesn't work but &lt;nowiki&gt;&lt;div id=&quot;location&quot;&gt;&lt;/nowiki&gt; works as in [[Oberon/System_Variants|Oberon/System_Variants]].
::: Thx, ... [[User:PeterEasthope|PeterEasthope]] ([[User talk:PeterEasthope|discuss]] • [[Special:Contributions/PeterEasthope|contribs]]) 15:18, 21 June 2026 (UTC)

== Template usage. ==

Hi,&lt;br&gt;
(1) A template declared in my account namespace works. Declared in the book namespace it doesn't work. Both cases are demonstrated in my [[User:PeterEasthope/sandbox]]. Declaration in the book is more direct; better not to depend upon an individual account. Ideas? Thx.

(2) If the desktop browser window is narrowed or the sandbox is viewed on a smartphone, the display is as illustrated [https://easthope.ca/WikimediaTemplate.jpg here]. How can the black perimeter frame be shrunk automatically to fit the background color boxes?

Thx,        ... [[User:PeterEasthope|PeterEasthope]] ([[User talk:PeterEasthope|discuss]] • [[Special:Contributions/PeterEasthope|contribs]]) 15:35, 21 June 2026 (UTC)</text>
      <sha1>sxy6ypsselca8qugdnstve487fljkh4</sha1>
    </revision>
  </page>
  <page>
    <title>Vehicle Identification Numbers (VIN codes)/Daihatsu/VIN Codes</title>
    <ns>0</ns>
    <id>485199</id>
    <revision>
      <id>4657040</id>
      <parentid>4656885</parentid>
      <timestamp>2026-08-10T14:23:06Z</timestamp>
      <contributor>
        <username>JustTheFacts33</username>
        <id>3434282</id>
      </contributor>
      <origin>4657040</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3241" sha1="mr2bzg78xzv2mx8zcdr8q8betgk95lc" xml:space="preserve">{{Vehicle Identification Numbers (VIN codes)/Warning}}{{clear}}

===Daihatsu WMIs===
The WMI is specified in characters 1-3 of the VIN.
* JD1 - Daihatsu Motor Company Ltd., Daihatsu Passenger Car
* JD2 - Daihatsu Motor Company Ltd., Daihatsu Multipurpose Passenger Vehicle (SUV)

===Body Style &amp; Transmission===
{| class=&quot;wikitable&quot; 
|+Position 4 
!Code
!Description
|-
|F
|Charade 3-d hatchback w/5-spd. man. trans. (1988-1992)
|-
|J
|Charade 3-d hatchback w/3-spd. auto. trans. (1989-1992)
|-
|E
|Charade 4-d sedan w/5-spd. man. trans. (1990-1992)
|-
|H
|Charade 4-d sedan w/3-spd. auto. trans. (1990-1992)
|-
|B
|Rocky hardtop w/5-spd. man. trans. (1990-1992)
|-
|F
|Rocky convertible w/5-spd. man. trans. (1990-1992)
|}

===Vehicle Line===
{| class=&quot;wikitable&quot; 
|+Position 5 
!Code
!Description
|-
|G
|Charade (1988-1992)
|-
|
|-
|F
|Rocky (1990-1992)
|}

===Model Designation===
{| class=&quot;wikitable&quot; 
|+Position 6 
|+Based on the Chassis code given for the car
!Code
!Description
|-
|1
|Charade w/1.0L engine ('88-'92): G'''1'''00 or w/1.3L engine ('89-'92): G'''1'''02
|-
|3
|Rocky ('90-'92): F'''3'''00
|}

===Series (Trim Level) &amp; Restraint System - For Passenger Cars===
{| class=&quot;wikitable&quot; 
|+Position 7 
!Code
!Description
|-
|0
|Charade CLS (1988), Manual seatbelts
|-
|1
|Charade CLX (1988), Manual seatbelts
|-
|2
|Charade CLX (1988), Door-mounted 2-point Automatic seatbelts and Manual Lap Belt
|-
|3
|Charade (1988) CSX, Manual seatbelts
|-
|1
|Charade CES (Mid 1989), Door-mounted 2-point Automatic seatbelts and Manual Lap Belt
|-
|2
|Charade CLS w/man. trans. (1989), Door-mounted 2-point Automatic seatbelts and Manual Lap Belt
|-
|6
|Charade CES (Early 1989), Manual seatbelts
|-
|7
|Charade CLS 1.3 w/auto. trans. (1989), Manual seatbelts
|-
|8
|Charade CLX (1989), Manual seatbelts
|-
|1
|Charade SE (1990-1992), Hatchback: Door-mounted 2-point Automatic seatbelts and Manual Lap Belt, Sedan: Motorized 2-point Automatic seatbelts and Manual Lap Belt
|-
|2
|Charade SX (1990-1992), Hatchback: Door-mounted 2-point Automatic seatbelts and Manual Lap Belt, Sedan: Motorized 2-point Automatic seatbelts and Manual Lap Belt
|}

===Series (Trim Level) &amp; GVWR - For MPVs===
{| class=&quot;wikitable&quot; 
|+Position 7 
!Code
!Description
|-
|1
|Rocky SE (1990-1992), Class B: 3001-4000 lbs. GVWR
|-
|2
|Rocky SX (1990-1992), Class B: 3001-4000 lbs. GVWR
|}

===Engine Type===
{| class=&quot;wikitable&quot;
|+Position 8
|-
! VIN !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes/Applications
|-
| 0 || 1.0L ||  I3 || Gas || SOHC,&lt;br /&gt; 6 valve || MPI. Daihatsu CB-90 engine. Charade ('88-'92).
|-
| 0 || 1.6L ||  I4 || Gas || SOHC,&lt;br /&gt; 16 valve || MPI. Daihatsu HD-E engine. Rocky ('90-'92).
|-
| 2 || 1.3L ||  I4 || Gas || SOHC,&lt;br /&gt; 16 valve || MPI. Daihatsu HC-E engine. Charade ('89-'92).
|}

===Position 9, Check Digit===
[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]

===Position 10, Model Year===                      
[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]

===Position 11, Production Plant:===
* 4:    Oyamazaki, Kyoto prefecture, Japan (Charade)
* 6:    Ikeda #2 Plant - Ikeda, Osaka prefecture, Japan (Rocky)

'''Positions 12–17, Serial Number'''

{{BookCat}}</text>
      <sha1>mr2bzg78xzv2mx8zcdr8q8betgk95lc</sha1>
    </revision>
  </page>
  <page>
    <title>General Literary Chinese from Scratch/Resolving a Succession Crisis with Emperor Trần Minh Tông</title>
    <ns>0</ns>
    <id>485204</id>
    <revision>
      <id>4657091</id>
      <timestamp>2026-08-10T19:46:57Z</timestamp>
      <contributor>
        <username>Shira the Mogul</username>
        <id>3560559</id>
      </contributor>
      <comment>Currently making a lesson plan involving this and it's incredibly interesting, definitely worth having in the textbook.</comment>
      <origin>4657091</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3208" sha1="dz15j4ch3hmuer4w4nc7nwqrtd5ius3" xml:space="preserve">[[File:CDVTranMinhTongjpg1333297930.jpg|thumb|200px|陳明宗]]
Comment to be written.

&lt;!---
Introduce Hồ Nguyên Trừng胡元澄 and his memoir, Nam Ông mộng lục南翁夢錄, which details his journey to becoming the Minister of Works for the Ming dynasty. Ask how much he knows about him.

In德必有位, he talks about Emperor Trần Minh Tông 陳明宗 and how his De 德 led to him maintaining his throne. Ask Dang how much he knows about Minh Tong and how he is seen in Vietnam. 

Detail a succession crisis:
-	There is a son born of a concubine (庶子); in this case, Crown Prince Trần Vượng.
-	The court ideally wants a son born of a wife (嫡子), and so successorship should wait until one comes.
-	Nhân Tông陳仁宗appears through relics to select the庶孫; that is, for Emperor Trần Minh Tông 陳明宗 to stay.

Trần Minh Tông interprets this as “restore the throne when he grows up,” which could endanger the polity! The officials warn that historically, this sort of succession crisis can pose serious risks to a nation. However, Trần Minh Tông blows this off: He is acting righteous towards a legitimate heir, and so there is no danger; he is prepared to surrender the throne to that heir. Unfortunately, the heir died a year later…and he grieved deeply. The problem disappeared because the legitimate heir died.
---&gt;

==Text==
===南翁夢錄·胡元澄===

====祖靈定命====
仁王示寂時，其子英王未有嫡嗣，止有庶子，意且待嫡子而後定嗣位。至茶毘後，封骨時，子孫環拜，舍利飛入庶孫袖裏而放光，既收，又入。英王拜曰：「敢不奉命？」收之，乃定。尋以庶子為世子。既久，嫡母生男，不育，庶子終嗣王位，是為明王。

====德必有位====
明王既嗣王位，久之，嫡母生男。至周晬時，英王巡邊在外，家事先決于嗣王。有司以周晬禮請，乃命以世子例行之。有司以王故，難之。王曰：「何疑乎？初以嫡嗣未生故，我權在此位。今既生矣，待長，復辟何難？」曰：「此事前古多危，請慎思之。」王曰：「順義行之，安危何足慮也！」卒以世子例行之。朞年而嫡嗣歿，王甚哀之，君子謂：明王誠心不顧于安危，讓德克光于今古，傳曰有德者，必有其位，其斯之謂歟！

===Notes===
* 嫡嗣：英宗與順聖保慈皇后所生之子，明宗之異母弟；名不傳。周晬後朞年而歿，故死時約二歲。
* 仁王、英王、明王：陳仁宗、陳英宗、陳明宗。
* 示寂、茶毘、舍利：皆佛教語。
* 庶子：此指陳奣，後為陳明宗；與嫡嗣相對。
* 嫡母：陳明宗父英宗之正妻，非其生母。
* 晬：《大越史記全書》：「晬音醉，周年也，子生一歲也。」
* 權：姑且、暫時。此處非「權力」義。
* 朞年：滿一年。
* 「有德者，必有其位」：參《中庸》：「故大德必得其位……故大德者必受命。」

==References==
* 《南翁夢錄·胡元澄》
* 《大越史記全書》：「晬音醉，周年也，子生一歲也。」
* 《中庸》：「故大德必得其位……故大德者必受命。」</text>
      <sha1>dz15j4ch3hmuer4w4nc7nwqrtd5ius3</sha1>
    </revision>
    <revision>
      <id>4657092</id>
      <parentid>4657091</parentid>
      <timestamp>2026-08-10T19:47:13Z</timestamp>
      <contributor>
        <username>Shira the Mogul</username>
        <id>3560559</id>
      </contributor>
      <minor />
      <origin>4657092</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3220" sha1="912bq4v9zldicbmoz6ou4mdszcwmcpo" xml:space="preserve">[[File:CDVTranMinhTongjpg1333297930.jpg|thumb|200px|陳明宗]]
Comment to be written.

&lt;!---
Introduce Hồ Nguyên Trừng胡元澄 and his memoir, Nam Ông mộng lục南翁夢錄, which details his journey to becoming the Minister of Works for the Ming dynasty. Ask how much he knows about him.

In德必有位, he talks about Emperor Trần Minh Tông 陳明宗 and how his De 德 led to him maintaining his throne. Ask Dang how much he knows about Minh Tong and how he is seen in Vietnam. 

Detail a succession crisis:
-	There is a son born of a concubine (庶子); in this case, Crown Prince Trần Vượng.
-	The court ideally wants a son born of a wife (嫡子), and so successorship should wait until one comes.
-	Nhân Tông陳仁宗appears through relics to select the庶孫; that is, for Emperor Trần Minh Tông 陳明宗 to stay.

Trần Minh Tông interprets this as “restore the throne when he grows up,” which could endanger the polity! The officials warn that historically, this sort of succession crisis can pose serious risks to a nation. However, Trần Minh Tông blows this off: He is acting righteous towards a legitimate heir, and so there is no danger; he is prepared to surrender the throne to that heir. Unfortunately, the heir died a year later…and he grieved deeply. The problem disappeared because the legitimate heir died.
---&gt;

==Text==
===南翁夢錄·胡元澄===

====祖靈定命====
仁王示寂時，其子英王未有嫡嗣，止有庶子，意且待嫡子而後定嗣位。至茶毘後，封骨時，子孫環拜，舍利飛入庶孫袖裏而放光，既收，又入。英王拜曰：「敢不奉命？」收之，乃定。尋以庶子為世子。既久，嫡母生男，不育，庶子終嗣王位，是為明王。

====德必有位====
明王既嗣王位，久之，嫡母生男。至周晬時，英王巡邊在外，家事先決于嗣王。有司以周晬禮請，乃命以世子例行之。有司以王故，難之。王曰：「何疑乎？初以嫡嗣未生故，我權在此位。今既生矣，待長，復辟何難？」曰：「此事前古多危，請慎思之。」王曰：「順義行之，安危何足慮也！」卒以世子例行之。朞年而嫡嗣歿，王甚哀之，君子謂：明王誠心不顧于安危，讓德克光于今古，傳曰有德者，必有其位，其斯之謂歟！

===Notes===
* 嫡嗣：英宗與順聖保慈皇后所生之子，明宗之異母弟；名不傳。周晬後朞年而歿，故死時約二歲。
* 仁王、英王、明王：陳仁宗、陳英宗、陳明宗。
* 示寂、茶毘、舍利：皆佛教語。
* 庶子：此指陳奣，後為陳明宗；與嫡嗣相對。
* 嫡母：陳明宗父英宗之正妻，非其生母。
* 晬：《大越史記全書》：「晬音醉，周年也，子生一歲也。」
* 權：姑且、暫時。此處非「權力」義。
* 朞年：滿一年。
* 「有德者，必有其位」：參《中庸》：「故大德必得其位……故大德者必受命。」

==References==
* 《南翁夢錄·胡元澄》
* 《大越史記全書》：「晬音醉，周年也，子生一歲也。」
* 《中庸》：「故大德必得其位……故大德者必受命。」
{{BookCat}}</text>
      <sha1>912bq4v9zldicbmoz6ou4mdszcwmcpo</sha1>
    </revision>
    <revision>
      <id>4657093</id>
      <parentid>4657092</parentid>
      <timestamp>2026-08-10T19:55:24Z</timestamp>
      <contributor>
        <username>Shira the Mogul</username>
        <id>3560559</id>
      </contributor>
      <minor />
      <comment>/* References */</comment>
      <origin>4657093</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3562" sha1="bwyq5mr3vfs11s5py1fgyqwxwx1uqy7" xml:space="preserve">[[File:CDVTranMinhTongjpg1333297930.jpg|thumb|200px|陳明宗]]
Comment to be written.

&lt;!---
Introduce Hồ Nguyên Trừng胡元澄 and his memoir, Nam Ông mộng lục南翁夢錄, which details his journey to becoming the Minister of Works for the Ming dynasty. Ask how much he knows about him.

In德必有位, he talks about Emperor Trần Minh Tông 陳明宗 and how his De 德 led to him maintaining his throne. Ask Dang how much he knows about Minh Tong and how he is seen in Vietnam. 

Detail a succession crisis:
-	There is a son born of a concubine (庶子); in this case, Crown Prince Trần Vượng.
-	The court ideally wants a son born of a wife (嫡子), and so successorship should wait until one comes.
-	Nhân Tông陳仁宗appears through relics to select the庶孫; that is, for Emperor Trần Minh Tông 陳明宗 to stay.

Trần Minh Tông interprets this as “restore the throne when he grows up,” which could endanger the polity! The officials warn that historically, this sort of succession crisis can pose serious risks to a nation. However, Trần Minh Tông blows this off: He is acting righteous towards a legitimate heir, and so there is no danger; he is prepared to surrender the throne to that heir. Unfortunately, the heir died a year later…and he grieved deeply. The problem disappeared because the legitimate heir died.
---&gt;

==Text==
===南翁夢錄·胡元澄===

====祖靈定命====
仁王示寂時，其子英王未有嫡嗣，止有庶子，意且待嫡子而後定嗣位。至茶毘後，封骨時，子孫環拜，舍利飛入庶孫袖裏而放光，既收，又入。英王拜曰：「敢不奉命？」收之，乃定。尋以庶子為世子。既久，嫡母生男，不育，庶子終嗣王位，是為明王。

====德必有位====
明王既嗣王位，久之，嫡母生男。至周晬時，英王巡邊在外，家事先決于嗣王。有司以周晬禮請，乃命以世子例行之。有司以王故，難之。王曰：「何疑乎？初以嫡嗣未生故，我權在此位。今既生矣，待長，復辟何難？」曰：「此事前古多危，請慎思之。」王曰：「順義行之，安危何足慮也！」卒以世子例行之。朞年而嫡嗣歿，王甚哀之，君子謂：明王誠心不顧于安危，讓德克光于今古，傳曰有德者，必有其位，其斯之謂歟！

===Notes===
* 嫡嗣：英宗與順聖保慈皇后所生之子，明宗之異母弟；名不傳。周晬後朞年而歿，故死時約二歲。
* 仁王、英王、明王：陳仁宗、陳英宗、陳明宗。
* 示寂、茶毘、舍利：皆佛教語。
* 庶子：此指陳奣，後為陳明宗；與嫡嗣相對。
* 嫡母：陳明宗父英宗之正妻，非其生母。
* 晬：《大越史記全書》：「晬音醉，周年也，子生一歲也。」
* 權：姑且、暫時。此處非「權力」義。
* 朞年：滿一年。
* 「有德者，必有其位」：參《中庸》：「故大德必得其位……故大德者必受命。」

==Questions==
# What is being talked about in this text? 
# What is the central problem?
# How does Emperor Trần Minh Tông 陳明宗 react to this problem?
# This is framed as ruling through virtue 德 and justice 義. What do you think of this?
# Why does Hồ mostly call the new son 嫡嗣, rather than describing him as 明王之弟?

==References==
* 《南翁夢錄·胡元澄》
* 《大越史記全書》：「晬音醉，周年也，子生一歲也。」
* 《中庸》：「故大德必得其位……故大德者必受命。」
{{BookCat}}</text>
      <sha1>bwyq5mr3vfs11s5py1fgyqwxwx1uqy7</sha1>
    </revision>
  </page>
  <page>
    <title>Wikibooks:Requests for deletion/Business Continuity Management</title>
    <ns>4</ns>
    <id>485205</id>
    <revision>
      <id>4657113</id>
      <timestamp>2026-08-11T00:00:49Z</timestamp>
      <contributor>
        <username>JJPMaster (bot)</username>
        <id>3488561</id>
      </contributor>
      <comment>Bot: Archiving closed deletion request — [[Special:Permalink/4656445#Business Continuity Management|Business Continuity Management]]</comment>
      <origin>4657113</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1485" sha1="d1ziztb34bhqnfo03rtvfonv4q6mjm0" xml:space="preserve">
== [[Business Continuity Management]] ==
{{closed|Deleted per consensus below. [[User:Codename Noreste|&lt;span style=&quot;color: blue&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 15:46, 5 August 2026 (UTC)}}
Largely abandoned for two decades and; consists of a single functional page with no indication of being fleshed out. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 14:04, 28 July 2026 (UTC)

:'''Delete''' ―[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''&lt;span style=&quot;color:black&quot;&gt;v&lt;/span&gt;f&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 16:18, 28 July 2026 (UTC)
:'''Delete'''. The single content page that was created - [[Business Continuity Management/Managing Business Continuity/Project Management]] - provides little sense of the intended organization of the book. I'm also a bit suspicious of the fact that it was created in a single edit, complete with comments like &quot;these [subjects] are discussed later in this chapter&quot;; this feels like it may have been copied from a print source, but I can't immediately identify what that might be. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 03:46, 2 August 2026 (UTC)
{{end closed}}</text>
      <sha1>d1ziztb34bhqnfo03rtvfonv4q6mjm0</sha1>
    </revision>
  </page>
  <page>
    <title>Wikibooks:Requests for deletion/Carbon Programming</title>
    <ns>4</ns>
    <id>485206</id>
    <revision>
      <id>4657114</id>
      <timestamp>2026-08-11T00:00:59Z</timestamp>
      <contributor>
        <username>JJPMaster (bot)</username>
        <id>3488561</id>
      </contributor>
      <comment>Bot: Archiving closed deletion request — [[Special:Permalink/4656445#Carbon Programming|Carbon Programming]]</comment>
      <origin>4657114</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1089" sha1="cekf0i31m22cdl57lg1roe5chodtrr3" xml:space="preserve">
== [[Carbon Programming]] ==
{{closed|Deleted per consensus below. [[User:Codename Noreste|&lt;span style=&quot;color: blue&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 15:44, 5 August 2026 (UTC)}}
Very minimal content on an outdated topic, with no development in 17 years. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 14:09, 28 July 2026 (UTC)

:'''Delete''' ―[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''&lt;span style=&quot;color:black&quot;&gt;v&lt;/span&gt;f&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 16:18, 28 July 2026 (UTC)
:'''Delete'''. No substantial content, and unlikely to be expanded given that Carbon is no longer available in  current versions of macOS. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 16:42, 28 July 2026 (UTC)
{{end closed}}</text>
      <sha1>cekf0i31m22cdl57lg1roe5chodtrr3</sha1>
    </revision>
  </page>
  <page>
    <title>Wikibooks:Requests for deletion/Confederate States Government</title>
    <ns>4</ns>
    <id>485207</id>
    <revision>
      <id>4657115</id>
      <timestamp>2026-08-11T00:01:09Z</timestamp>
      <contributor>
        <username>JJPMaster (bot)</username>
        <id>3488561</id>
      </contributor>
      <comment>Bot: Archiving closed deletion request — [[Special:Permalink/4656445#Confederate States Government|Confederate States Government]]</comment>
      <origin>4657115</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1187" sha1="gp4gphjzpdjdypsbbzh9j1qtxcd2y1e" xml:space="preserve">
== [[Confederate States Government]] ==
{{closed|Deleted per consensus below. [[User:Codename Noreste|&lt;span style=&quot;color: blue&quot;&gt;Codename Noreste&lt;/span&gt;]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 15:42, 5 August 2026 (UTC)}}
Abandoned for 20 years with minimal content and no evidence of development. —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 14:19, 28 July 2026 (UTC)

:'''Delete''' ―[[User:Koavf|Justin (&lt;span style=&quot;color:grey&quot;&gt;ko'''a'''&lt;span style=&quot;color:black&quot;&gt;v&lt;/span&gt;f&lt;/span&gt;)]]&lt;span style=&quot;color:red&quot;&gt;❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯&lt;/span&gt; 16:18, 28 July 2026 (UTC)
:'''Delete'''. The single content page, [[Confederate States Government/Election of Lincoln]], is no more than a very short summary of [[:w:1860 United States presidential election]]. There is no other substance to the book. [[User:Omphalographer|Omphalographer]] ([[User talk:Omphalographer|discuss]] • [[Special:Contributions/Omphalographer|contribs]]) 04:19, 2 August 2026 (UTC)
{{end closed}}</text>
      <sha1>gp4gphjzpdjdypsbbzh9j1qtxcd2y1e</sha1>
    </revision>
  </page>
  <page>
    <title>User talk:Prishku</title>
    <ns>3</ns>
    <id>485208</id>
    <revision>
      <id>4657118</id>
      <timestamp>2026-08-11T00:36:39Z</timestamp>
      <contributor>
        <username>JJPMaster</username>
        <id>3095725</id>
      </contributor>
      <comment>Notifying author of speedy deletion</comment>
      <origin>4657118</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="726" sha1="sv5wl9vjz7suaaieqc3j0mxgjshgkg1" xml:space="preserve">
== Your page has been speedily deleted ==
Hi! I'm JJPMaster, and I recently reviewed your page, [[:Chess Opening Theory/1. d4/1...c5/2. d5/2...e5/3. e4]]. However, it does not meet Wikibooks's [[Wikibooks:What is Wikibooks?|standards for inclusion]], and it has therefore been [[Wikibooks:Deletion policy|deleted]]. The reason I provided was: &lt;blockquote&gt;&lt;strong&gt;test edit&lt;/strong&gt;&lt;/blockquote&gt; If you believe that your page should not have been deleted, or you have any questions or concerns, please [[User talk:JJPMaster|let me know]]. Thank you! [[User:JJPMaster|JJP]]&lt;sub&gt;[[User talk:JJPMaster|Mas]]&lt;sub&gt;[[Special:Contributions/JJPMaster|ter]]&lt;/sub&gt;&lt;/sub&gt; ([[wikt:she|she]]/[[wikt:they|they]]) 00:36, 11 August 2026 (UTC)</text>
      <sha1>sv5wl9vjz7suaaieqc3j0mxgjshgkg1</sha1>
    </revision>
  </page>
  <page>
    <title>An Introduction to Dragon/Lessons/Installation</title>
    <ns>0</ns>
    <id>485209</id>
    <revision>
      <id>4657139</id>
      <timestamp>2026-08-11T08:02:56Z</timestamp>
      <contributor>
        <username>~2026-44191-83</username>
        <id>3620656</id>
      </contributor>
      <comment>Updated book content as per new version of Dragon</comment>
      <origin>4657139</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1865" sha1="6ocl8md27c7pr74xj7cq1raay0v67t3" xml:space="preserve">== Installation and Building from Source ==

Dragon is currently distributed as source and built with '''Cargo''', so a recent stable [https://www.rust-lang.org/tools/install Rust toolchain] (edition 2021) is required.

=== Cloning and building ===

&lt;syntaxhighlight lang=&quot;bash&quot;&gt;
# Clone the repository
git clone https://github.com/aaveshdev/dragon.git
cd dragon

# Build the CLI in debug mode
cargo build

# Build an optimized release binary (recommended)
cargo build --release
&lt;/syntaxhighlight&gt;

The compiled CLI binary is produced as &lt;code&gt;dragon&lt;/code&gt; (or &lt;code&gt;dragon.exe&lt;/code&gt; on Windows) at:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
target/release/dragon
&lt;/syntaxhighlight&gt;

Cargo also builds a shared library (&lt;code&gt;dragon_lib&lt;/code&gt;, i.e. &lt;code&gt;dragon_lib.dll&lt;/code&gt; / &lt;code&gt;libdragon_lib.so&lt;/code&gt; / &lt;code&gt;libdragon_lib.dylib&lt;/code&gt;) automatically alongside the CLI, since the library target's crate type includes both &lt;code&gt;cdylib&lt;/code&gt; and &lt;code&gt;rlib&lt;/code&gt;.

=== Installing the CLI globally ===

&lt;syntaxhighlight lang=&quot;bash&quot;&gt;
cargo install --path .
&lt;/syntaxhighlight&gt;

This installs the &lt;code&gt;dragon&lt;/code&gt; binary onto your &lt;code&gt;PATH&lt;/code&gt;, so it can be invoked from any directory.

=== Feature and target notes ===

* '''Native codegen''' (&lt;code&gt;--native&lt;/code&gt;) shells out to a system C compiler (&lt;code&gt;gcc&lt;/code&gt;, &lt;code&gt;clang&lt;/code&gt;, or &lt;code&gt;cl&lt;/code&gt; on Windows), so one of these must be on your &lt;code&gt;PATH&lt;/code&gt; for that feature to work.
* '''Android''' targets pull in &lt;code&gt;jni&lt;/code&gt; / &lt;code&gt;ndk&lt;/code&gt; dependencies automatically.
* '''WASM''' targets pull in &lt;code&gt;wasm-bindgen&lt;/code&gt; / &lt;code&gt;web-sys&lt;/code&gt; / &lt;code&gt;getrandom&lt;/code&gt; automatically.
* On &lt;code&gt;aarch64-unknown-linux-gnu&lt;/code&gt;, OpenSSL is vendored and built from source, so a C toolchain is required there as well.

=== License ===

Dragon is licensed under the '''MIT License'''.</text>
      <sha1>6ocl8md27c7pr74xj7cq1raay0v67t3</sha1>
    </revision>
    <revision>
      <id>4657145</id>
      <parentid>4657139</parentid>
      <timestamp>2026-08-11T08:16:04Z</timestamp>
      <contributor>
        <username>MathXplore</username>
        <id>3097823</id>
      </contributor>
      <minor />
      <comment>Added {{[[Template:BookCat|BookCat]]}} using [[User:1234qwer1234qwer4/BookCat.js|BookCat.js]]</comment>
      <origin>4657145</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1878" sha1="lex8rz3klrvocidbrvd2jjoonusei0r" xml:space="preserve">== Installation and Building from Source ==

Dragon is currently distributed as source and built with '''Cargo''', so a recent stable [https://www.rust-lang.org/tools/install Rust toolchain] (edition 2021) is required.

=== Cloning and building ===

&lt;syntaxhighlight lang=&quot;bash&quot;&gt;
# Clone the repository
git clone https://github.com/aaveshdev/dragon.git
cd dragon

# Build the CLI in debug mode
cargo build

# Build an optimized release binary (recommended)
cargo build --release
&lt;/syntaxhighlight&gt;

The compiled CLI binary is produced as &lt;code&gt;dragon&lt;/code&gt; (or &lt;code&gt;dragon.exe&lt;/code&gt; on Windows) at:

&lt;syntaxhighlight lang=&quot;text&quot;&gt;
target/release/dragon
&lt;/syntaxhighlight&gt;

Cargo also builds a shared library (&lt;code&gt;dragon_lib&lt;/code&gt;, i.e. &lt;code&gt;dragon_lib.dll&lt;/code&gt; / &lt;code&gt;libdragon_lib.so&lt;/code&gt; / &lt;code&gt;libdragon_lib.dylib&lt;/code&gt;) automatically alongside the CLI, since the library target's crate type includes both &lt;code&gt;cdylib&lt;/code&gt; and &lt;code&gt;rlib&lt;/code&gt;.

=== Installing the CLI globally ===

&lt;syntaxhighlight lang=&quot;bash&quot;&gt;
cargo install --path .
&lt;/syntaxhighlight&gt;

This installs the &lt;code&gt;dragon&lt;/code&gt; binary onto your &lt;code&gt;PATH&lt;/code&gt;, so it can be invoked from any directory.

=== Feature and target notes ===

* '''Native codegen''' (&lt;code&gt;--native&lt;/code&gt;) shells out to a system C compiler (&lt;code&gt;gcc&lt;/code&gt;, &lt;code&gt;clang&lt;/code&gt;, or &lt;code&gt;cl&lt;/code&gt; on Windows), so one of these must be on your &lt;code&gt;PATH&lt;/code&gt; for that feature to work.
* '''Android''' targets pull in &lt;code&gt;jni&lt;/code&gt; / &lt;code&gt;ndk&lt;/code&gt; dependencies automatically.
* '''WASM''' targets pull in &lt;code&gt;wasm-bindgen&lt;/code&gt; / &lt;code&gt;web-sys&lt;/code&gt; / &lt;code&gt;getrandom&lt;/code&gt; automatically.
* On &lt;code&gt;aarch64-unknown-linux-gnu&lt;/code&gt;, OpenSSL is vendored and built from source, so a C toolchain is required there as well.

=== License ===

Dragon is licensed under the '''MIT License'''.

{{BookCat}}</text>
      <sha1>lex8rz3klrvocidbrvd2jjoonusei0r</sha1>
    </revision>
  </page>
  <page>
    <title>User:AkramTheArtist</title>
    <ns>2</ns>
    <id>485210</id>
    <revision>
      <id>4657154</id>
      <timestamp>2026-08-11T10:17:20Z</timestamp>
      <contributor>
        <username>AkramTheArtist</username>
        <id>3522432</id>
      </contributor>
      <comment>Created page with &quot;&lt;div dir=&quot;rtl&quot; style=&quot;width:100%;max-width:900px;margin:auto;text-align:right;&quot;&gt;&lt;div style=&quot;width:100%;max-width:390px;margin:0 auto;border:1px solid #c8c8c8;background:#f8f9fa;text-align:center;&quot;&gt;&lt;div style=&quot;background:#d5d3ff;padding:10px;font-size:22px;font-weight:bold;&quot;&gt; أكرم محمد السراي &lt;/div&gt;&lt;div style=&quot;background:#eeeeff;padding:9px;font-size:16px;&quot;&gt; فنان تشكيلي عراقي معاصر &lt;/div&gt;&lt;div style=&quot;background:#eeeeff;padding:9px;font-siz...&quot;</comment>
      <origin>4657154</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2628" sha1="g0tlrys7906ammcu78eziika70pqij1" xml:space="preserve">&lt;div dir=&quot;rtl&quot; style=&quot;width:100%;max-width:900px;margin:auto;text-align:right;&quot;&gt;&lt;div style=&quot;width:100%;max-width:390px;margin:0 auto;border:1px solid #c8c8c8;background:#f8f9fa;text-align:center;&quot;&gt;&lt;div style=&quot;background:#d5d3ff;padding:10px;font-size:22px;font-weight:bold;&quot;&gt;
أكرم محمد السراي
&lt;/div&gt;&lt;div style=&quot;background:#eeeeff;padding:9px;font-size:16px;&quot;&gt;
فنان تشكيلي عراقي معاصر
&lt;/div&gt;&lt;div style=&quot;background:#eeeeff;padding:9px;font-size:16px;&quot;&gt;
Akram Mohammed Al-Sarray
&lt;/div&gt;&lt;div style=&quot;padding:10px;background:#ffffff;&quot;&gt;
[[File:أكرم_محمد_السراي.png|375x375px|أكرم محمد السراي]]
&lt;/div&gt;&lt;div style=&quot;background:#d5d3ff;padding:8px;font-size:18px;font-weight:bold;&quot;&gt;
معلومات شخصية
&lt;/div&gt;
{| style=&quot;width:100%;font-size:15px;&quot;
! style=&quot;background:#eeeeff;width:40%;padding:8px;text-align:right;&quot; |تاريخ الميلاد
| style=&quot;padding:8px;text-align:right;&quot; |28 أبريل 2002
|-
! style=&quot;background:#eeeeff;padding:8px;text-align:right;&quot; |مكان الميلاد
| style=&quot;padding:8px;text-align:right;&quot; |ذي قار، العراق
|-
! style=&quot;background:#eeeeff;padding:8px;text-align:right;&quot; |الجنسية
| style=&quot;padding:8px;text-align:right;&quot; |عراقي
|}
&lt;div style=&quot;background:#d5d3ff;padding:8px;font-size:18px;font-weight:bold;&quot;&gt;
الحياة العملية
&lt;/div&gt;
{| style=&quot;width:100%;font-size:15px;&quot;
! style=&quot;background:#eeeeff;width:40%;padding:8px;text-align:right;&quot; |المهنة
| style=&quot;padding:8px;text-align:right;&quot; |فنان تشكيلي
|-
! style=&quot;background:#eeeeff;padding:8px;text-align:right;&quot; |مجال العمل
| style=&quot;padding:8px;text-align:right;&quot; |الرسم والفن التشكيلي
|-
! style=&quot;background:#eeeeff;padding:8px;text-align:right;&quot; |التعليم
| style=&quot;padding:8px;text-align:right;&quot; |معهد الفنون الجميلة – الديوانية
|-
! style=&quot;background:#eeeeff;padding:8px;text-align:right;&quot; |العضوية
| style=&quot;padding:8px;text-align:right;&quot; |نقابة الفنانين العراقيين
|}
&lt;div style=&quot;background:#d5d3ff;padding:8px;font-size:18px;font-weight:bold;&quot;&gt;
عن أكرم
&lt;/div&gt;&lt;div style=&quot;padding:15px;line-height:1.9;&quot;&gt;
'''أكرم محمد السراي''' فنان تشكيلي عراقي معاصر، يهتم بالرسم والفن التشكيلي والثقافة والتراث العراقي.

تتناول تجربته الفنية موضوعات الإنسان والهوية والذاكرة والتراث العراقي، مع اهتمام بالبيئة الجنوبية العراقية ورموزها البصرية.
&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</text>
      <sha1>g0tlrys7906ammcu78eziika70pqij1</sha1>
    </revision>
    <revision>
      <id>4657157</id>
      <parentid>4657154</parentid>
      <timestamp>2026-08-11T11:41:45Z</timestamp>
      <contributor>
        <username>MathXplore</username>
        <id>3097823</id>
      </contributor>
      <comment>Requesting deletion ([[:m:Special:MyLanguage/User:TenWhile6/XReport|XReport]] v3.1c)</comment>
      <origin>4657157</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2757" sha1="fwpd96487rin3dr4xvsk7rtuf2g5ftc" xml:space="preserve">&lt;noinclude&gt;{{delete|1=Out of project scope &lt;small&gt;[[:m:Special:MyLanguage/User:TenWhile6/XReport|XReport]]&lt;/small&gt;}}&lt;/noinclude&gt;
&lt;div dir=&quot;rtl&quot; style=&quot;width:100%;max-width:900px;margin:auto;text-align:right;&quot;&gt;&lt;div style=&quot;width:100%;max-width:390px;margin:0 auto;border:1px solid #c8c8c8;background:#f8f9fa;text-align:center;&quot;&gt;&lt;div style=&quot;background:#d5d3ff;padding:10px;font-size:22px;font-weight:bold;&quot;&gt;
أكرم محمد السراي
&lt;/div&gt;&lt;div style=&quot;background:#eeeeff;padding:9px;font-size:16px;&quot;&gt;
فنان تشكيلي عراقي معاصر
&lt;/div&gt;&lt;div style=&quot;background:#eeeeff;padding:9px;font-size:16px;&quot;&gt;
Akram Mohammed Al-Sarray
&lt;/div&gt;&lt;div style=&quot;padding:10px;background:#ffffff;&quot;&gt;
[[File:أكرم_محمد_السراي.png|375x375px|أكرم محمد السراي]]
&lt;/div&gt;&lt;div style=&quot;background:#d5d3ff;padding:8px;font-size:18px;font-weight:bold;&quot;&gt;
معلومات شخصية
&lt;/div&gt;
{| style=&quot;width:100%;font-size:15px;&quot;
! style=&quot;background:#eeeeff;width:40%;padding:8px;text-align:right;&quot; |تاريخ الميلاد
| style=&quot;padding:8px;text-align:right;&quot; |28 أبريل 2002
|-
! style=&quot;background:#eeeeff;padding:8px;text-align:right;&quot; |مكان الميلاد
| style=&quot;padding:8px;text-align:right;&quot; |ذي قار، العراق
|-
! style=&quot;background:#eeeeff;padding:8px;text-align:right;&quot; |الجنسية
| style=&quot;padding:8px;text-align:right;&quot; |عراقي
|}
&lt;div style=&quot;background:#d5d3ff;padding:8px;font-size:18px;font-weight:bold;&quot;&gt;
الحياة العملية
&lt;/div&gt;
{| style=&quot;width:100%;font-size:15px;&quot;
! style=&quot;background:#eeeeff;width:40%;padding:8px;text-align:right;&quot; |المهنة
| style=&quot;padding:8px;text-align:right;&quot; |فنان تشكيلي
|-
! style=&quot;background:#eeeeff;padding:8px;text-align:right;&quot; |مجال العمل
| style=&quot;padding:8px;text-align:right;&quot; |الرسم والفن التشكيلي
|-
! style=&quot;background:#eeeeff;padding:8px;text-align:right;&quot; |التعليم
| style=&quot;padding:8px;text-align:right;&quot; |معهد الفنون الجميلة – الديوانية
|-
! style=&quot;background:#eeeeff;padding:8px;text-align:right;&quot; |العضوية
| style=&quot;padding:8px;text-align:right;&quot; |نقابة الفنانين العراقيين
|}
&lt;div style=&quot;background:#d5d3ff;padding:8px;font-size:18px;font-weight:bold;&quot;&gt;
عن أكرم
&lt;/div&gt;&lt;div style=&quot;padding:15px;line-height:1.9;&quot;&gt;
'''أكرم محمد السراي''' فنان تشكيلي عراقي معاصر، يهتم بالرسم والفن التشكيلي والثقافة والتراث العراقي.

تتناول تجربته الفنية موضوعات الإنسان والهوية والذاكرة والتراث العراقي، مع اهتمام بالبيئة الجنوبية العراقية ورموزها البصرية.
&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</text>
      <sha1>fwpd96487rin3dr4xvsk7rtuf2g5ftc</sha1>
    </revision>
  </page>
</mediawiki>