I have recieved an EOMA68-A20 2.7.4 preproduction computer card and the 1.7 micro desktop (MD) last week. Just for clarification these boards are nothing new and have been discussed on this mailing list. If some of you already have their preproduction boards ready, I would appreciate any help, hints and suggestions to help me getting started.
Altough I have some experience with handling arm-boards I am now afraid to do something **stupid** and break/fry the boards. After some digging in the list-archives I found this thread ([1]) where Richard and Luke discuss how to connect the bare computer card with the bare micro desktop. I have many questions: 1. Connecting computer card and micro desktop: I am aware of the photos attached to [2]. Does the mentioned video exist? Richard, did you send photos to Luke? (If yes, can I have them?) Luke, do you want me to send you photos too before apllying power?
2. PSU for micro desktop: According to the mentioned thread ([1]): "5.5mm jack with a 2.1mm centre hole, middle is +ve (aka "pin positive")", "Anywhere between 7 and 21v is fine, minimum 1A, 1 5A is better"
So I searched for a DC PSU in my household and read Wikipedia where it is mentioned that OD 5.5 mm / ID 2.1 mm is common on guitar effect pedals but my multi guitar effect pedal PSU did not fit (ID too small). Finally I found a matching DC PSU from a low volatage guitar amp. It says O / P: DC 15V, 2A and a symbol (positive polarity): L. P. S. - -(.- +
So I think this should be good to go. Can anyone please confirm. Thank you.
Should we document this somewhere on rhombus-tech.net?
3. Soldering iron ready: I have my soldering iron ready. Richard, did you solder UART pins to the micro desktop ([3])?
4. SD-card ready / U-Boot Tried to compile u-boot-sunxi [4] and make exits with "System not configured". So Luke, what did you use as config or has something changed over the years? I also tried mainline U-Boot but could not find "EOMA68-A20-foo_defconfig" and "sun7i-eoma68-a20-foo.dts". What kind of defconfig and *.dts was used for the mainline U-Boot demos? My search of the mailing list archives and rhombus-tech was not futile. I could only dig up an old thread from 2014 where wookey was "assigned" to work on a minimal dts/dtb.
5. Git, notes and documentation Finally I am wondering where to put my notes. A subpage on rhombus-tech seems like a good idea good to me and indicates a work in progress in contrast to the various wikis out there. Where do you want me to push my work in progress git branches if I manage to hack something useful together?
Pablo
References: [1] http://lists.phcomp.co.uk/pipermail/arm-netbook/2019-July/016149.html [2] http://lists.phcomp.co.uk/pipermail/arm-netbook/2019-July/016154.html [3] http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20190722/914a328... [4] http://rhombus-tech.net/allwinner/a20/boot/
On Tuesday, 16 June 2020 10:44:47 CEST Pablo Rath wrote:
I have recieved an EOMA68-A20 2.7.4 preproduction computer card and the 1.7 micro desktop (MD) last week. Just for clarification these boards are nothing new and have been discussed on this mailing list. If some of you already have their preproduction boards ready, I would appreciate any help, hints and suggestions to help me getting started.
I certainly don't have one, nor are there likely to be many in circulation, but maybe there are some people assisting Luke who have some experience with them. Without reviewing the previous threads, I can't give you any quick and/ or reliable answers to your questions.
However, I did summarise the state of certain things on the wiki at one point:
http://rhombus-tech.net/crowdsupply/status/
- Git, notes and documentation
Finally I am wondering where to put my notes. A subpage on rhombus-tech seems like a good idea good to me and indicates a work in progress in contrast to the various wikis out there. Where do you want me to push my work in progress git branches if I manage to hack something useful together?
You could probably make a wiki page on the rhombus-tech site with your notes, maybe linking to it from the one mentioned above.
One thing I can imagine is that some kernel issues are likely to be much easier than when Luke was trying to get a kernel together, mostly because quite a bit of mainlining has since taken place, although I can't guarantee that the notorious Linux 4.7 bug mentioned on that page is still there or not.
Still, it will be interesting to follow your investigations.
Paul
On Wed, Jun 17, 2020 at 01:09:42AM +0200, Paul Boddie wrote:
On Tuesday, 16 June 2020 10:44:47 CEST Pablo Rath wrote:
[..]
If some of you already have their preproduction boards ready, I would appreciate any help, hints and suggestions to help me getting started.
I certainly don't have one, nor are there likely to be many in circulation, but maybe there are some people assisting Luke who have some experience with them.
My hope is that a handful of boards made it to some developers who signed up on rhombus-tech. The only confirmation of one board out in the wild I have is Richard Wilburs email with questions. I am waiting as patiently as I can, but the itch to do something grows stronger. Over the years I grew quite fond of eoma68 and this mailing-list and the progress and success of this project is very important to me.
[...]
However, I did summarise the state of certain things on the wiki at one point:
Thanks for your reply and for reminding me of your summary. It was a good refresher for me.
- Git, notes and documentation
Finally I am wondering where to put my notes. A subpage on rhombus-tech seems like a good idea good to me and indicates a work in progress in contrast to the various wikis out there. Where do you want me to push my work in progress git branches if I manage to hack something useful together?
You could probably make a wiki page on the rhombus-tech site with your notes, maybe linking to it from the one mentioned above.
Sounds good to me. Let us wait on Lukes reply to see if he agrees.
kind regards Pablo
On Tue, Jun 16, 2020 at 9:45 AM Pablo Rath pablo@parobalth.org wrote:
I have recieved an EOMA68-A20 2.7.4 preproduction computer card and the 1.7 micro desktop (MD) last week. Just for clarification these boards are nothing new and have been discussed on this mailing list. If some of you already have their preproduction boards ready, I would appreciate any help, hints and suggestions to help me getting started.
Altough I have some experience with handling arm-boards I am now afraid to do something **stupid** and break/fry the boards. After some digging in the list-archives I found this thread ([1]) where Richard and Luke discuss how to connect the bare computer card with the bare micro desktop. I have many questions:
- Connecting computer card and micro desktop:
I am aware of the photos attached to [2]. Does the mentioned video exist?
no.
Richard, did you send photos to Luke? (If yes, can I have them?) Luke, do you want me to send you photos too before apllying power?
yes that would be good. visually it is pretty obvious. just do *not* bend or waggle the Card as it's inserted (however you may find that the connector is soldered at a slight angle of 1 to 3 degrees).
from visual inspection from the top, the gap left and right should be equal. this should be logically fairly obvious.
from visual inspection from the front, it should also be obvious if the card has been inserted where the top row of pins has gone into the bottom part of the connector or vice-versa.
If You Can See Pins You Got It Wrong.
also, once inserted, place the anti-static bag *in between* the Card and the MicroDesktop PCB.
- PSU for micro desktop:
According to the mentioned thread ([1]): "5.5mm jack with a 2.1mm centre hole, middle is +ve (aka "pin positive")", "Anywhere between 7 and 21v is fine, minimum 1A, 1 5A is better"
So I searched for a DC PSU in my household and read Wikipedia where it is mentioned that OD 5.5 mm / ID 2.1 mm is common on guitar effect pedals but my multi guitar effect pedal PSU did not fit (ID too small). Finally I found a matching DC PSU from a low volatage guitar amp. It says O / P: DC 15V, 2A and a symbol (positive polarity): L. P. S.
- -(.- +
you're better off checking with a multimeter. it's pretty standard (pin positive) however there is no substitute for actually checking. i.e.: don't guess - check. hardware is unforgiving.
So I think this should be good to go. Can anyone please confirm. Thank you.
Should we document this somewhere on rhombus-tech.net?
yes, good idea.
- SD-card ready / U-Boot
Tried to compile u-boot-sunxi [4] and make exits with "System not configured". So Luke, what did you use as config
it's on the wiki somewhere. it has been 5 years so i will be searching just as much as you would be.
or has something changed over the years?
no.
I also tried mainline U-Boot but could not find "EOMA68-A20-foo_defconfig" and "sun7i-eoma68-a20-foo.dts". What kind of defconfig and *.dts was used for the mainline U-Boot demos? My search of the mailing list archives and rhombus-tech was not futile. I could only dig up an old thread from 2014 where wookey was "assigned" to work on a minimal dts/dtb.
- Git, notes and documentation
Finally I am wondering where to put my notes. A subpage on rhombus-tech seems like a good idea good to me
yes.
and indicates a work in progress in contrast to the various wikis out there. Where do you want me to push my work in progress git branches if I manage to hack something useful together?
i never needed to make any modifications to any linux kernel or u-boot source code, so one has not been set up.
l.
On Wed, Jul 08, 2020 at 11:46:49AM +0100, Luke Kenneth Casson Leighton wrote:
On Tue, Jun 16, 2020 at 9:45 AM Pablo Rath pablo@parobalth.org wrote:
I have recieved an EOMA68-A20 2.7.4 preproduction computer card and the 1.7 micro desktop (MD) last week. Just for clarification these boards are nothing new and have been discussed on this mailing list. If some of you already have their preproduction boards ready, I would appreciate any help, hints and suggestions to help me getting started.
Altough I have some experience with handling arm-boards I am now afraid to do something **stupid** and break/fry the boards. After some digging in the list-archives I found this thread ([1]) where Richard and Luke discuss how to connect the bare computer card with the bare micro desktop. I have many questions:
- Connecting computer card and micro desktop:
I am aware of the photos attached to [2]. Does the mentioned video exist?
no.
Richard, did you send photos to Luke? (If yes, can I have them?) Luke, do you want me to send you photos too before apllying power?
yes that would be good. visually it is pretty obvious. just do *not* bend or waggle the Card as it's inserted (however you may find that the connector is soldered at a slight angle of 1 to 3 degrees).
from visual inspection from the top, the gap left and right should be equal. this should be logically fairly obvious.
Images can be found here (I could not upload them to the rhombus-tech wiki becaus a virus checker is not defined): https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_1.JPG https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_2.JPG https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_3.JPG https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_4.JPG
from visual inspection from the front, it should also be obvious if the card has been inserted where the top row of pins has gone into the bottom part of the connector or vice-versa.
Visual inspection from the front looks good to me but is difficult to photograph with good light and correct focus.
If You Can See Pins You Got It Wrong.
I can't see pins anymore.
also, once inserted, place the anti-static bag *in between* the Card and the MicroDesktop PCB.
Is this for anti-static purpose or to add a bit of stability? Do you fold your bag to fit the entire length of computer-card?
- PSU for micro desktop:
According to the mentioned thread ([1]): "5.5mm jack with a 2.1mm centre hole, middle is +ve (aka "pin positive")", "Anywhere between 7 and 21v is fine, minimum 1A, 1 5A is better"
So I searched for a DC PSU in my household and read Wikipedia where it is mentioned that OD 5.5 mm / ID 2.1 mm is common on guitar effect pedals but my multi guitar effect pedal PSU did not fit (ID too small). Finally I found a matching DC PSU from a low volatage guitar amp. It says O / P: DC 15V, 2A and a symbol (positive polarity): L. P. S.
- -(.- +
you're better off checking with a multimeter. it's pretty standard (pin positive) however there is no substitute for actually checking. i.e.: don't guess - check. hardware is unforgiving.
Bought a multimeter and checked. DC PSU is good to go.
Should we document this somewhere on rhombus-tech.net?
yes, good idea.
Will do it in next couple of days.
- SD-card ready / U-Boot
Tried to compile u-boot-sunxi [4] and make exits with "System not configured". So Luke, what did you use as config
it's on the wiki somewhere. it has been 5 years so i will be searching just as much as you would be.
Ok.
or has something changed over the years?
no.
- Git, notes and documentation
Finally I am wondering where to put my notes. A subpage on rhombus-tech seems like a good idea good to me
yes.
After a quick check it seems one can not create subpages from the online editor (only edit pages). Can I still send you an ssh-key to get a better access to the wiki?
and indicates a work in progress in contrast to the various wikis out there. Where do you want me to push my work in progress git branches if I manage to hack something useful together?
i never needed to make any modifications to any linux kernel or u-boot source code, so one has not been set up.
Ok. Thanks.
kind regards Pablo
Forgive the horribly embarrassingly so-late-it's-early chime-in from a dork on his phone :P but it's worth noting that antistatic bags are generally conductive on one side (and only one side!) -- especially the darkly-translucent aluminized Mylar kind.
It strikes me that getting that conductive side oriented in the wrong direction could prove spectacularly catastrophic, so I thought I'd pipe up about that...
I mean, fireworks can be fun, but usually not that kind, and as far as I know all the major holidays involving such things are either already over or way later in the year... could be wrong tho. ( :P )
...but seriously, let's keep the "magic smoke" inside the componentry where it belongs ;) IIRC most of those shiny-ish bags should be multimeter-verifiable as to which side is which.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Jul 9, 2020 at 11:40 AM Christopher Havel laserhawk64@gmail.com wrote:
Forgive the horribly embarrassingly so-late-it's-early chime-in from a dork on his phone :P but it's worth noting that antistatic bags are generally conductive on one side (and only one side!) -- especially the darkly-translucent aluminized Mylar kind.
ah. that's good to know :)
i've never had any issues with this, perhaps a different type of bag?
still if you are concerned, pablo, use a piece of paper instead. just please not a plastic bag (PC, Nylon, PVA)
it goes without saying that you should not be wearing your favourite polyester shirt, rubber-soled shoes and the 70s nylon fashionable trousers and the brown wool hairy cardigan [i actually had one of those], doing this all on the shag rug carpet.
if you don't have an anti-static mat (with the strap and everything) then a tiled floor, wooden desk, and if you have a radiator nearby or you know *for a fact* that a piece of electrical or electronic equipment has an earth connection (many laptop PSUs *DO NOT HAVE GROUND*) just touch the metal before handling the PCBs ok?
l.
On Thu, Jul 09, 2020 at 11:49:02AM +0100, Luke Kenneth Casson Leighton wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Jul 9, 2020 at 11:40 AM Christopher Havel laserhawk64@gmail.com wrote:
Forgive the horribly embarrassingly so-late-it's-early chime-in from a dork on his phone :P but it's worth noting that antistatic bags are generally conductive on one side (and only one side!) -- especially the darkly-translucent aluminized Mylar kind.
ah. that's good to know :)
i've never had any issues with this, perhaps a different type of bag?
still if you are concerned, pablo, use a piece of paper instead. just please not a plastic bag (PC, Nylon, PVA)
it goes without saying that you should not be wearing your favourite polyester shirt, rubber-soled shoes and the 70s nylon fashionable trousers and the brown wool hairy cardigan [i actually had one of those], doing this all on the shag rug carpet.
if you don't have an anti-static mat (with the strap and everything) then a tiled floor, wooden desk, and if you have a radiator nearby or you know *for a fact* that a piece of electrical or electronic equipment has an earth connection (many laptop PSUs *DO NOT HAVE GROUND*) just touch the metal before handling the PCBs ok?
Thank you both for the warning and advice. I am going to take it serious and be careful.
...besides that your wording is absolutley hilarious. Just imagine me in the described 70s outfit amidst whisps of *magic smoke*...
On Thu, Jul 9, 2020 at 11:28 AM Pablo Rath pablo@parobalth.org wrote:
Images can be found here (I could not upload them to the rhombus-tech wiki becaus a virus checker is not defined):
ah sorry :)
ok can you re-take this one *exactly* from above? as it is slightly to the side it is not visually possible to confirm that the gap on the left is exactly the same as the gap on the right, because perspective (and shadows).
it's slightly out of focus, the camera selected the ASICs not the connector, didn't it?
ah that's better.
ah ha! cancel that on the 1st one, that looks even on both sides, doesn't it?
ok there's one more: a picture from the *underside* - actually *between* the PCBs (try to get some light in there). don't for goodness sake pry the cards apart, obviously you'll need to take the anti-static bag out.
whilst the no 4. photo showed that the pins from the *top* row are not showing, i.e. the Card was not inserted too low, this does *NOT* guarantee that the card was inserted TOO HIGH.
and you will find that out by VERY CAREFULLY inspecting *between* the PCBs. if the Card was inserted 1.5 mm too high, you will be able to see the bottom PCMCIA row of pins clearly.
BE CAREFUL ok?
from visual inspection from the front, it should also be obvious if the card has been inserted where the top row of pins has gone into the bottom part of the connector or vice-versa.
Visual inspection from the front looks good to me but is difficult to photograph with good light and correct focus.
If You Can See Pins You Got It Wrong.
I can't see pins anymore.
you need to check top and bottom. top looks good, bottom also needs checking.
also, once inserted, place the anti-static bag *in between* the Card and the MicroDesktop PCB.
Is this for anti-static purpose or to add a bit of stability?
although it has that effect, it's there to protect against possible short-circuit. the top of the MD is lacquered, and there are no components, however why take the risk?
anti-static means that when handling - inserting the bag - you don't zap anything.
Do you fold your bag to fit the entire length of computer-card?
nonono, that would put pressure on the PCB and bend the connector. just slide it in gently in a U-shape.
you're better off checking with a multimeter. it's pretty standard (pin positive) however there is no substitute for actually checking. i.e.: don't guess - check. hardware is unforgiving.
Bought a multimeter and checked. DC PSU is good to go.
staaaar :)
Should we document this somewhere on rhombus-tech.net?
yes, good idea.
Will do it in next couple of days.
- SD-card ready / U-Boot
Tried to compile u-boot-sunxi [4] and make exits with "System not configured". So Luke, what did you use as config
it's on the wiki somewhere. it has been 5 years so i will be searching just as much as you would be.
Ok.
there should be some a20_defconfigs... sitemap... arse. no, let's try the git repo instead... http://rhombus-tech.net/allwinner_a10/boot/
AH! GOT IT: http://rhombus-tech.net/allwinner/a20/boot/
there you go.
After a quick check it seems one can not create subpages from the online editor (only edit pages).
yes, this is standard practice. you create the link on the parent, first, then it creates a question-mark, then you get an edit link. if you know what you're doing you can manually create edit links :)
Can I still send you an ssh-key to get a better access to the wiki?
sure. that would help you as well as you can use "find" etc.
in case it wasn't obvious, thank you for this. pablo. i really appreciate you taking the time to get this sorted.
l.
On Thu, Jul 09, 2020 at 11:43:58AM +0100, Luke Kenneth Casson Leighton wrote:
On Thu, Jul 9, 2020 at 11:28 AM Pablo Rath pablo@parobalth.org wrote:
ah that's better.
ah ha! cancel that on the 1st one, that looks even on both sides, doesn't it?
Yes, looks even to me.
ok there's one more: a picture from the *underside* - actually *between* the PCBs (try to get some light in there). don't for goodness sake pry the cards apart, obviously you'll need to take the anti-static bag out.
whilst the no 4. photo showed that the pins from the *top* row are not showing, i.e. the Card was not inserted too low, this does *NOT* guarantee that the card was inserted TOO HIGH.
and you will find that out by VERY CAREFULLY inspecting *between* the PCBs. if the Card was inserted 1.5 mm too high, you will be able to see the bottom PCMCIA row of pins clearly.
BE CAREFUL ok?
I am extremely careful. I triple checked from all sides and especially from the *underside* and there are no pins visible. I tried to take a picture yesterday and today in good daylight, with and without camera flash, with and without additional lighting but I can't get a usable picture *between* the PCBs. I wish you could see through my eyes :) I think we have to trust in my assessment. I am *very* confident that the connection is correct.
from visual inspection from the front, it should also be obvious if the card has been inserted where the top row of pins has gone into the bottom part of the connector or vice-versa.
Visual inspection from the front looks good to me but is difficult to photograph with good light and correct focus.
If You Can See Pins You Got It Wrong.
I can't see pins anymore.
you need to check top and bottom. top looks good, bottom also needs checking.
Done like described above.
also, once inserted, place the anti-static bag *in between* the Card and the MicroDesktop PCB.
Is this for anti-static purpose or to add a bit of stability?
although it has that effect, it's there to protect against possible short-circuit. the top of the MD is lacquered, and there are no components, however why take the risk?
anti-static means that when handling - inserting the bag - you don't zap anything.
Do you fold your bag to fit the entire length of computer-card?
nonono, that would put pressure on the PCB and bend the connector. just slide it in gently in a U-shape.
Ok.
- SD-card ready / U-Boot
Tried to compile u-boot-sunxi [4] and make exits with "System not configured". So Luke, what did you use as config
it's on the wiki somewhere. it has been 5 years so i will be searching just as much as you would be.
Ok.
there should be some a20_defconfigs... sitemap... arse. no, let's try the git repo instead... http://rhombus-tech.net/allwinner_a10/boot/
AH! GOT IT: http://rhombus-tech.net/allwinner/a20/boot/
there you go.
Ah, yes. This is what I found and mentioned in my email. Thank you for looking it up and confirming. Will give it another try.
After a quick check it seems one can not create subpages from the online editor (only edit pages).
yes, this is standard practice. you create the link on the parent, first, then it creates a question-mark, then you get an edit link. if you know what you're doing you can manually create edit links :)
Thank you for the crash course. Worked... almost like... *magic*. I have created a subpage under a20 and will put everthing there and we can move individual sections later if necessary.
in case it wasn't obvious, thank you for this. pablo. i really appreciate you taking the time to get this sorted.
It is kind of obvious but still nice when explicitly mentioned. :)
So the next and last step hardware wise is to solder the UART connection to the micro desktop? Can I use standard pin headers?
kind regards Pablo
On Thu, Jul 09, 2020 at 11:43:58AM +0100, Luke Kenneth Casson Leighton wrote:
So the next and last step hardware wise is to solder the UART connection to the micro desktop? Can I use standard pin headers?
yehyeh. that's what it's for. standard 2.54mm pitch. it's designed precisely for that.
actually i soldered directly to the PCB. don't tell no-one :)
http://rhombus-tech.net/allwinner/a20/eoma68_a20_usb_uart_connect.jpg
there you will see *only* GND, TX and RX connected. do not *under any circumstances* connect the VCC_IO line. this is a reference power supply *from the USB UART*. so is the 3.3v supply from the EOMA68 PCB.
if you connect them together they will destroy each other.
given that USB UART is "pulldown" (floating indicates LOW) it is perfectly fine not to have a converter IC. which normally would be the responsibility of the developer to create an external PCB that did that. if they wanted to. rather than use the pins as GPIO.
when doing it this way (without a converter IC) you will find however that even just the power coming from the TX and RX pins is enough to provide 3.3v to the actual A20 processor.
therefore you *will* need to disconnect the USB cable when powering down. simply switching off the 12v PSU (15v in your case) is *not enough*.
also watch out for GROUND loops between:
* laptop / desktop PSU * laptop / desktop * USB UART port connected to laptop * EOMA68 PCB * 12 (15) volt PSU
if you get problems (which will show up as corrupted data and possible eventual destruction of the FT232 USB UART IC - yes this is just how it goes) then disconnect the laptop's PSU whilst powering on.
i have in the past hotwired a 5V USB cable (cut the connector off) directly into the 5V rail of the micro-desktop PCB, bypassing the RT power converter IC. if you happen to have one of those "back-to-back USB cables" around (i had one for a laptop fan base for example) then you could actually plug that back-to-back USB cable directly into one of the micro-desktop USB ports.
the USB power is connected straight to the 5.0V rail, which in turn (through a SY6280 current limiter) powers the EOMA68 Card.
that way you could plug the back-to-back USB cable into the *same device* as what you also plug in the USB-UART, and you will not end up with 240v mains-related power fluctuations on the GND cables.
which as i warned you about, in some PSUs might not actually exist (particularly cheap PSUs - they have a plastic GND pin here in the UK).
when that happens the *only way* that you get a common GND reference is actually *through the EOMA68 PCB* via the USB cable, and that really does not go down well when there is a large amount of 240v 50 hz EMI being radiated about.
l.
On Friday, 10 July 2020 08:59:07 CEST Pablo Rath wrote:
On Thu, Jul 09, 2020 at 11:43:58AM +0100, Luke Kenneth Casson Leighton
wrote:
yes, this is standard practice. you create the link on the parent, first, then it creates a question-mark, then you get an edit link. if you know what you're doing you can manually create edit links :)
Thank you for the crash course. Worked... almost like... *magic*. I have created a subpage under a20 and will put everthing there and we can move individual sections later if necessary.
I think I had similar problems until I realised that it is all very "old- school wiki", first creating links for new pages in existing pages, then getting the magic question mark, and then having the opportunity to create the new page. I suppose it encourages people to link to new content and to consider whether they really need a new page.
I saw that there is a section about legacy U-Boot in the page:
http://rhombus-tech.net/allwinner/a20/EOMA68-A20_2-7-4_preproduction/
The experience I had with old U-Boot versions that were contemporary with older versions of GCC is that the compiler-tweaking headers from Linux generally spew out lots of errors with newer compilers. One apparent solution was to just copy in the header from a more recent version of Linux (or maybe U-Boot) which is what I did for the MIPS Creator CI20 U-Boot, copying from a more recent version of Linux:
cp ../CI20_linux-ci20-v3.18/include/linux/compiler-gcc.h include/linux
However, that doesn't seem to be sufficient here. The structure of the Linux headers have changed, and while newer U-Boot versions seem to have adopted this structure, it doesn't seem to be easy to introduce to the legacy U-Boot for the Allwinner boards.
So, what seems to be necessary is to get an older compiler and to use that instead. Since distributions retire older compilers regularly, I used Buildroot to create a suitable GCC 4.9 cross-compiler than can then build the legacy U-Boot. To make things complicated here, Buildroot also retires support for older compilers, so I had to find a version still supporting GCC 4.x that didn't also suffer from this issue:
https://git.busybox.net/buildroot/commit/? id=c48f8a64626c60bd1b46804b7cf1a699ff53cdf3
Anyway, here are the commands I used:
git clone git://git.buildroot.net/buildroot cd buildroot git checkout 2018.08.4 make menuconfig
In the menu, the following settings were inspected/changed:
Target options Target Architecture (ARM (little endian)) Target Binary Format (ELF) Target Architecture Variant Target ABI (EABIhf) Floating point strategy (NEON/VFPv4) ARM instruction set (ARM)
Toolchain GCC compiler Version (gcc 4.9.x)
To build the toolchain, run...
make toolchain
(Use -j <processes> for parallel builds, of course. You may need to install rsync if you haven't already done so. Other packages may also be necessary.)
Setting PATH to reference this toolchain in output/host/bin, you can now build the legacy U-Boot as follows:
git clone https://github.com/linux-sunxi/u-boot-sunxi.git cd u-boot-sunxi make CROSS_COMPILE=arm-linux- EOMA68_A20_config make CROSS_COMPILE=arm-linux-
(Again, use -j <processes> to make this go faster. Note that Buildroot compilers tend to use their own naming, so it is arm-linux- and not arm-linux- gnueabihf- that needs to be used.)
Here, the use of EOMA68_A20_config sets up a bootloader for SD cards, whereas EOMA68_A20_FEL_config would set up a USB-bootable payload. See here for all the details:
https://github.com/linux-sunxi/u-boot-sunxi/wiki
This should get you the u-boot-sunxi-with-spl.bin file that needs to be deployed.
Hope this was helpful!
Paul
On Sat, Jul 18, 2020 at 07:19:37PM +0200, Paul Boddie wrote:
I saw that there is a section about legacy U-Boot in the page:
http://rhombus-tech.net/allwinner/a20/EOMA68-A20_2-7-4_preproduction/
Yes, obviously I had to start with U-Boot first. Luke told me that sunxi U-Boot should build fine and that nothing has changed so I started there.
For mainline U-Boot I still need a valid config file to do 'make eoma68_foo_defconfig'. There is a .dts file here (http://rhombus-tech.net/allwinner/a20/boot/sun7i-a20-eoma68-a20.dts) but I don't know if it was used for mainline U-Boot and not just for Kernel compilation.
The experience I had with old U-Boot versions that were contemporary with older versions of GCC is that the compiler-tweaking headers from Linux generally spew out lots of errors with newer compilers. One apparent solution was to just copy in the header from a more recent version of Linux (or maybe U-Boot) which is what I did for the MIPS Creator CI20 U-Boot, copying from a more recent version of Linux:
cp ../CI20_linux-ci20-v3.18/include/linux/compiler-gcc.h include/linux
However, that doesn't seem to be sufficient here. The structure of the Linux headers have changed, and while newer U-Boot versions seem to have adopted this structure, it doesn't seem to be easy to introduce to the legacy U-Boot for the Allwinner boards.
So, what seems to be necessary is to get an older compiler and to use that instead. Since distributions retire older compilers regularly, I used Buildroot to create a suitable GCC 4.9 cross-compiler than can then build the legacy U-Boot.
I have realised that on Debian gcc versions are kept installed. I have a native armhf installation (initially installed with Jessie) currently upgraded to stretch and gcc-4.9 is still installed. Changed between gcc versions with 'update-alternatives'. I don't know if this also apllies to cross-toolchains because my experience with crossbuilding is limited.
Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages so this could be another solution I have not tested yes as I have no armhf sid installation.
To make things complicated here, Buildroot also retires support for older compilers, so I had to find a version still supporting GCC 4.x that didn't also suffer from this issue:
https://git.busybox.net/buildroot/commit/? id=c48f8a64626c60bd1b46804b7cf1a699ff53cdf3
Anyway, here are the commands I used:
git clone git://git.buildroot.net/buildroot cd buildroot git checkout 2018.08.4 make menuconfig
In the menu, the following settings were inspected/changed:
Target options Target Architecture (ARM (little endian)) Target Binary Format (ELF) Target Architecture Variant Target ABI (EABIhf) Floating point strategy (NEON/VFPv4) ARM instruction set (ARM)
Toolchain GCC compiler Version (gcc 4.9.x)
To build the toolchain, run...
make toolchain
(Use -j <processes> for parallel builds, of course. You may need to install rsync if you haven't already done so. Other packages may also be necessary.)
Setting PATH to reference this toolchain in output/host/bin, you can now build the legacy U-Boot as follows:
git clone https://github.com/linux-sunxi/u-boot-sunxi.git cd u-boot-sunxi make CROSS_COMPILE=arm-linux- EOMA68_A20_config make CROSS_COMPILE=arm-linux-
(Again, use -j <processes> to make this go faster. Note that Buildroot compilers tend to use their own naming, so it is arm-linux- and not arm-linux- gnueabihf- that needs to be used.)
This is extremly helpful. I am going to try it out. Can you copy that to the wiki? Maybe as a separate subpage or at the end. I think we should keep everything short and clear for those who know what they are doing but still provide enough hand-holding and external context for those with less experience.
Here, the use of EOMA68_A20_config sets up a bootloader for SD cards, whereas EOMA68_A20_FEL_config would set up a USB-bootable payload. See here for all the details:
https://github.com/linux-sunxi/u-boot-sunxi/wiki
This should get you the u-boot-sunxi-with-spl.bin file that needs to be deployed.
Good news is that I made it to the sunxi U-Boot prompt on Friday. Booted via USB-FEL. So my soldered Pins, UART connection, Power Supply, µUSB-OTG on the card work fine.
Next I have planned to compile a sunxi 3.4 Kernel and debootstrap a Debian rootfs. Then I want to try mainline U-Boot and a mainline Kernel. Feel free to share your solutions and best practices with me!
Hope this was helpful!
Thank you for your help. Please add to the wiki.
Pablo
(btw thank you paul - and pablo - both)
On Sun, Jul 19, 2020 at 12:18 PM Pablo Rath pablo@parobalth.org wrote:
On Sat, Jul 18, 2020 at 07:19:37PM +0200, Paul Boddie wrote:
I saw that there is a section about legacy U-Boot in the page:
http://rhombus-tech.net/allwinner/a20/EOMA68-A20_2-7-4_preproduction/
Yes, obviously I had to start with U-Boot first. Luke told me that sunxi U-Boot should build fine and that nothing has changed so I started there.
For mainline U-Boot I still need a valid config file to do 'make eoma68_foo_defconfig'. There is a .dts file here (http://rhombus-tech.net/allwinner/a20/boot/sun7i-a20-eoma68-a20.dts) but I don't know if it was used for mainline U-Boot and not just for Kernel compilation.
it would be both (for mainline in each case).
I have realised that on Debian gcc versions are kept installed.
yes, i have 35 separate different gcc compiler packages installed and unfortunately at some point i removed the gnueabihf arm 4.7.2 one. damn
I have a native armhf installation (initially installed with Jessie) currently upgraded to stretch and gcc-4.9 is still installed. Changed between gcc versions with 'update-alternatives'. I don't know if this also apllies to cross-toolchains because my experience with crossbuilding is limited.
export the right environment variables and it's not necessary to use "update-alternatives".
export CC=gcc-4.9 export CROSS_COMPILE=arm-linux-gnueabihf- (or something) export ARCH=arm
or just:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CC=gcc-4.9 {insertwhatever}
yes, here you go, the "make blah blah" lines: http://rhombus-tech.net/allwinner/a20/boot/
just add the extra parameter CC=gcc-4.9 (or gcc-4.7)
Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages so this could be another solution I have not tested yes as I have no armhf sid installation.
arse. this is the earliest i can find so far.
http://ftp.debian.org/debian/pool/main/g/gcc-6-cross/
that *might* be back far enough to work.
This is extremly helpful. I am going to try it out. Can you copy that to the wiki?
yes please, paul.
This should get you the u-boot-sunxi-with-spl.bin file that needs to be deployed.
Good news is that I made it to the sunxi U-Boot prompt on Friday. Booted via USB-FEL. So my soldered Pins, UART connection, Power Supply, µUSB-OTG on the card work fine.
fantastic!
Next I have planned to compile a sunxi 3.4 Kernel and debootstrap a Debian rootfs.
you should pretty much be able to download and use anything. use debootstrap if you like (in cross-arch mode). this you can do using qemu-arm to "prepare / finish" things. actually there's now a qemu-debootstrap command so it should be dead simple:
http://logan.tw/posts/2017/01/21/introduction-to-qemu-debootstrap/
Then I want to try mainline U-Boot and a mainline Kernel.
good idea.
l.
On Sunday, 19 July 2020 14:17:21 CEST Luke Kenneth Casson Leighton wrote:
(btw thank you paul - and pablo - both)
On Sun, Jul 19, 2020 at 12:18 PM Pablo Rath pablo@parobalth.org wrote:
This is extremly helpful. I am going to try it out. Can you copy that to the wiki?
yes please, paul.
OK, I've updated this page...
http://rhombus-tech.net/allwinner_a10/source_code/
It now links to these pages:
http://rhombus-tech.net/allwinner_a10/Buildroot_Toolchain/ http://rhombus-tech.net/allwinner_a10/Building_U-Boot/
Hopefully, it still makes sense and can be followed by anyone wanting to get involved with this.
Paul
On Sunday, July 19, 2020, Paul Boddie paul@boddie.org.uk wrote:
OK, I've updated this page...
http://rhombus-tech.net/allwinner_a10/source_code/
It now links to these pages:
http://rhombus-tech.net/allwinner_a10/Buildroot_Toolchain/ http://rhombus-tech.net/allwinner_a10/Building_U-Boot/
thank you paul, that's really appreciated.
l.
On Sun, Jul 19, 2020 at 01:17:21PM +0100, Luke Kenneth Casson Leighton wrote:
Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages so this could be another solution I have not tested yes as I have no armhf sid installation.
arse. this is the earliest i can find so far.
http://ftp.debian.org/debian/pool/main/g/gcc-6-cross/
that *might* be back far enough to work.
debian does have an archive site somewhere where they keep totally obsolete and discontinued distributions. It may be worth while looking for it. I no longer have the link to that site, but I did use it once to find a discontinued package. I managed to download the source package. However, it had so many build-time dependencies that is turned out to be essentially useless.
gcc just might have fewer dependencies. Maybe you can still find the one that works for you.
-- hendrik
On Sunday, July 19, 2020, Hendrik Boom hendrik@topoi.pooq.com wrote:
On Sun, Jul 19, 2020 at 01:17:21PM +0100, Luke Kenneth Casson Leighton wrote:
Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages so this could be another solution I have not tested yes as I have no armhf sid installation.
arse. this is the earliest i can find so far.
http://ftp.debian.org/debian/pool/main/g/gcc-6-cross/
that *might* be back far enough to work.
debian does have an archive site somewhere where they keep totally obsolete and discontinued distributions.
http://archive.debian.org is supposed to be that location.
however the pool directory does not contain gcc cross compilers.
l.
On Sunday, 19 July 2020 17:32:41 CEST Luke Kenneth Casson Leighton wrote:
On Sunday, July 19, 2020, Hendrik Boom hendrik@topoi.pooq.com wrote:
debian does have an archive site somewhere where they keep totally obsolete and discontinued distributions.
http://archive.debian.org is supposed to be that location.
however the pool directory does not contain gcc cross compilers.
Cross-compilers are relatively new in Debian as broadly supported things (ignoring things like Atmel cross-compilers and one-off attempts at providing toolchains for some release architectures). I think that they first made it into the distribution properly for Stretch, meaning that we're only on the second release that has them.
Also, older packages probably have all sorts of dependencies on older distribution versions, and with that there's the need to virtualise or chroot entire software distributions. And then, it might turn out that the precise configuration of the compilers isn't entirely suitable, as I have discovered for various SoCs in the past [*].
Paul
[*] However, that was actually related to soft-float support for MIPS, which needs to be configured at build-time for GCC, but which was omitted from the Debian toolchains because the assumption is that all the code compiled by the Debian compiler will be deployed on Linux, and Linux has run-time support for floating point instruction emulation (that a bare metal or alternative environment might not have). But in general, you cannot be too careful with some of this stuff, and not all shortcuts turn out to be what they seemed to be.
On Sun, Jul 19, 2020 at 01:17:21PM +0100, Luke Kenneth Casson Leighton wrote:
[...]
For mainline U-Boot I still need a valid config file to do 'make eoma68_foo_defconfig'. There is a .dts file here (http://rhombus-tech.net/allwinner/a20/boot/sun7i-a20-eoma68-a20.dts) but I don't know if it was used for mainline U-Boot and not just for Kernel compilation.
it would be both (for mainline in each case).
Ok. But what did you use as defconfig in configs/ (U-Boot mainline)?
I have realised that on Debian gcc versions are kept installed.
yes, i have 35 separate different gcc compiler packages installed and unfortunately at some point i removed the gnueabihf arm 4.7.2 one. damn
I have a native armhf installation (initially installed with Jessie) currently upgraded to stretch and gcc-4.9 is still installed. Changed between gcc versions with 'update-alternatives'. I don't know if this also apllies to cross-toolchains because my experience with crossbuilding is limited.
export the right environment variables and it's not necessary to use "update-alternatives".
export CC=gcc-4.9 export CROSS_COMPILE=arm-linux-gnueabihf- (or something) export ARCH=arm
or just:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CC=gcc-4.9 {insertwhatever}
yes, here you go, the "make blah blah" lines: http://rhombus-tech.net/allwinner/a20/boot/
just add the extra parameter CC=gcc-4.9 (or gcc-4.7)
I have read about CC=gcc-foo and tried but it did not work as expected. Maybe I did something wrong. Will try again.
Pablo
On Sun, Jul 19, 2020 at 9:02 PM Pablo Rath pablo@parobalth.org wrote:
Ok. But what did you use as defconfig in configs/ (U-Boot mainline)?
it was 4 years ago: your guess is as good as mine, unless i happened to put it in the wiki somewhere.
l.
On Sunday, 19 July 2020 22:19:37 CEST Luke Kenneth Casson Leighton wrote:
On Sun, Jul 19, 2020 at 9:02 PM Pablo Rath pablo@parobalth.org wrote:
Ok. But what did you use as defconfig in configs/ (U-Boot mainline)?
it was 4 years ago: your guess is as good as mine, unless i happened to put it in the wiki somewhere.
Currently, I am updating this page:
http://rhombus-tech.net/allwinner_a10/Building_Linux/
On which I noted that the boot page...
http://rhombus-tech.net/allwinner/a20/boot/
...provides a special configuration (eoma68-a20-4.7-config) that would presumably get copied into the configs directory as some kind of defconfig. However, it is probably superseded by the sunxi_defconfig file now, for the most part.
It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very similar to that from the Cubietruck 2. Were the differences documented and are there any schematics to provide any necessary insight when updating the device tree? (Since these things appear to change all the time - or just decay - in the Linux kernel distribution.)
Paul
On Sun, Jul 19, 2020 at 9:35 PM Paul Boddie paul@boddie.org.uk wrote:
On Sunday, 19 July 2020 22:19:37 CEST Luke Kenneth Casson Leighton wrote:
On Sun, Jul 19, 2020 at 9:02 PM Pablo Rath pablo@parobalth.org wrote:
Ok. But what did you use as defconfig in configs/ (U-Boot mainline)?
it was 4 years ago: your guess is as good as mine, unless i happened to put it in the wiki somewhere.
Currently, I am updating this page:
http://rhombus-tech.net/allwinner_a10/Building_Linux/
On which I noted that the boot page...
http://rhombus-tech.net/allwinner/a20/boot/
...provides a special configuration (eoma68-a20-4.7-config) that would presumably get copied into the configs directory as some kind of defconfig. However, it is probably superseded by the sunxi_defconfig file now, for the most part.
sounds about right.
It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very similar to that from the Cubietruck 2.
that sounds about right. possibly the original cubieboard.
Were the differences documented and are there any schematics to provide any necessary insight when updating the device tree?
there's PDFs somewhere... http://hands.com/~lkcl/eoma/ such as this: http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf
the thing is that it is critically important that the dts file *do not* include the peripherals associated with the "Boards" (Micro-Desktop, 15in laptop). the peripheral sets *MUST* go into a "dynamic include" file that is detected at boot time and "inserted" into the live device-tree.
this functionality - dynamic runtime "insertion" of device-tree fragments - was an idea *in development* back in.... 2013 we have had to wait several years for this functionality to make its way into both u-boot and the linux kernel.
l.
On Sunday, 19 July 2020 22:43:59 CEST Luke Kenneth Casson Leighton wrote:
On Sun, Jul 19, 2020 at 9:35 PM Paul Boddie paul@boddie.org.uk wrote:
It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very similar to that from the Cubietruck 2.
that sounds about right. possibly the original cubieboard.
OK. From what I can see, there are strong similarities between the above file and both sun4i-a10-cubieboard.dts and sun7i-a20-cubieboard2.dts. (I got mixed up and wrote Cubietruck 2 above.)
The principal differences appear to be as follows:
The EOMA68-A20 DT doesn't have HDMI nodes whereas the Cubieboard DTs have nodes for HDMI connectors and the usual peripheral nodes (&hdmi, &hdmi_out). Given the effort that went into putting micro-HDMI on the computer card, I guess there might be some definitions to add here.
The EOMA68-A20 DT has a special pinctrl node for mmc3_cd_pin (MMC3 card detect, I guess). There are also LED pin differences, but I think these are explained by pin definitions migrating to the sun7i-a20.dtsi file.
Some I2C definitions seem to be different in the Cubieboard DTs, but that could also be due to pin definitions migrating to the sun7i-a20.dtsi file.
The Cubieboard DTs enable the display engine (&de) and power (&ac_power_supply).
There are some changes to the Ethernet node (&gmac). (I didn't think Ethernet was exposed by the computer cards when the specification was updated after the first round of cards being made.)
The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT has a node ®_usb0_vbus that the other DTs do not have.
So, it seems possible that an updated DT file would be a minor variation on the Cubieboard 2 file.
Were the differences documented and are there any schematics to provide any necessary insight when updating the device tree?
there's PDFs somewhere... http://hands.com/~lkcl/eoma/ such as this: http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf
And, as usual, when I go to download it, I find that I already have it alongside a schematic for the Cubietruck!
the thing is that it is critically important that the dts file *do not* include the peripherals associated with the "Boards" (Micro-Desktop, 15in laptop). the peripheral sets *MUST* go into a "dynamic include" file that is detected at boot time and "inserted" into the live device-tree.
Indeed. I guess the computer card device tree sits at a level between the chipset device tree and what would normally be the machine device tree.
this functionality - dynamic runtime "insertion" of device-tree fragments - was an idea *in development* back in.... 2013 we have had to wait several years for this functionality to make its way into both u-boot and the linux kernel.
I guess I should ask whether such support made it into either of them.
Paul
On Sunday, July 19, 2020, Paul Boddie paul@boddie.org.uk wrote:
On Sunday, 19 July 2020 22:43:59 CEST Luke Kenneth Casson Leighton wrote:
On Sun, Jul 19, 2020 at 9:35 PM Paul Boddie paul@boddie.org.uk wrote:
It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very
similar
to that from the Cubietruck 2.
that sounds about right. possibly the original cubieboard.
OK. From what I can see, there are strong similarities between the above file and both sun4i-a10-cubieboard.dts and sun7i-a20-cubieboard2.dts. (I got mixed up and wrote Cubietruck 2 above.)
The principal differences appear to be as follows:
The EOMA68-A20 DT doesn't have HDMI nodes whereas the Cubieboard DTs have nodes for HDMI connectors and the usual peripheral nodes (&hdmi, &hdmi_out). Given the effort that went into putting micro-HDMI on the computer card, I guess there might be some definitions to add here.
yes.
The EOMA68-A20 DT has a special pinctrl node for mmc3_cd_pin (MMC3 card detect, I guess). There are also LED pin differences, but I think these are explained by pin definitions migrating to the sun7i-a20.dtsi file.
ah. the updates to the hardware it is now mmc0
Some I2C definitions seem to be different in the Cubieboard DTs, but that could also be due to pin definitions migrating to the sun7i-a20.dtsi file.
The Cubieboard DTs enable the display engine (&de) and power (&ac_power_supply).
There are some changes to the Ethernet node (&gmac). (I didn't think Ethernet was exposed by the computer cards when the specification was updated after the first round of cards being made.)
no it's gone
The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT has a node ®_usb0_vbus that the other DTs do not have.
So, it seems possible that an updated DT file would be a minor variation on the Cubieboard 2 file.
pretty much.
Were the differences documented and are there any schematics to provide any necessary insight when updating the device
tree?
there's PDFs somewhere... http://hands.com/~lkcl/eoma/ such as this: http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf
And, as usual, when I go to download it, I find that I already have it alongside a schematic for the Cubietruck!
:)
the thing is that it is critically important that the dts file *do not* include the peripherals associated with the "Boards" (Micro-Desktop, 15in laptop). the peripheral sets *MUST* go into a "dynamic include" file that is detected at boot time and "inserted" into the live device-tree.
Indeed. I guess the computer card device tree sits at a level between the chipset device tree and what would normally be the machine device tree.
if i understand you correctly: not quite.
the closest equivalent is 96boards and arduino shield dtbs.
here the 96boards dtb file *is* the machine level.
the pin header dtb locations however are NOT FILLED IN.
they instead have special references - pointers. each pointer is named (given the pin number) but is set to NULL by default.
at RUNTIME - not "device tree compile time" - at **RUNTIME** - a special command is run with a "shield dtb fragment" that directly and DYNAMICALLY replaces those named parameter pointers with the reference to the dtb fragment.
this functionality - dynamic runtime "insertion" of device-tree fragments - was an idea *in development* back in.... 2013 we have had to wait several years for this functionality to make its way into both u-boot and the linux kernel.
I guess I should ask whether such support made it into either of them.
investigating 96boards and how their shields are supported should give some leads, there.
the absolute last thing needed however is hardcoded static compiled dtb, one for eoma68-a20-microdesktop, one for laptop, then one for eoma68-rk3288-microdesktop
it would be utterly disastrous for EOMA68 to consider the base dtb file to be a "chipset" level tree.
it has to be a *board* level (machine level) tree because of the standalone nature of EOMA68 Cards.
however all 68 pins are "shield" pins, *not* "machine" pins, and need to be dynamically connected just like for 96boards shields.
l.
On Monday, 20 July 2020 00:20:58 CEST Luke Kenneth Casson Leighton wrote:
On Sunday, July 19, 2020, Paul Boddie paul@boddie.org.uk wrote:
The principal differences appear to be as follows:
The EOMA68-A20 DT doesn't have HDMI nodes whereas the Cubieboard DTs have nodes for HDMI connectors and the usual peripheral nodes (&hdmi, &hdmi_out). Given the effort that went into putting micro-HDMI on the computer card, I guess there might be some definitions to add here.
yes.
OK, I'll add them.
The EOMA68-A20 DT has a special pinctrl node for mmc3_cd_pin (MMC3 card detect, I guess). There are also LED pin differences, but I think these are explained by pin definitions migrating to the sun7i-a20.dtsi file.
ah. the updates to the hardware it is now mmc0
OK.
Some I2C definitions seem to be different in the Cubieboard DTs, but that could also be due to pin definitions migrating to the sun7i-a20.dtsi file.
The Cubieboard DTs enable the display engine (&de) and power (&ac_power_supply).
There are some changes to the Ethernet node (&gmac). (I didn't think Ethernet was exposed by the computer cards when the specification was updated after the first round of cards being made.)
no it's gone
OK.
The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT has a node ®_usb0_vbus that the other DTs do not have.
So, it seems possible that an updated DT file would be a minor variation on the Cubieboard 2 file.
pretty much.
I'll have to look at the OTG thing to figure out its significance.
[...]
Indeed. I guess the computer card device tree sits at a level between the chipset device tree and what would normally be the machine device tree.
if i understand you correctly: not quite.
the closest equivalent is 96boards and arduino shield dtbs.
here the 96boards dtb file *is* the machine level.
the pin header dtb locations however are NOT FILLED IN.
they instead have special references - pointers. each pointer is named (given the pin number) but is set to NULL by default.
at RUNTIME - not "device tree compile time" - at **RUNTIME** - a special command is run with a "shield dtb fragment" that directly and DYNAMICALLY replaces those named parameter pointers with the reference to the dtb fragment.
I understood the run-time aspect, but I thought that the specialisation would be a bit like the way something like the Cubieboard DT specialises the A20 DT.
So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or enables various peripherals, and then - at run-time - each housing's DT which activates the peripherals that were exposed but not enabled.
I guess the challenge is to describe the peripherals in a neutral way in the housing's DT so as not to taint them with the specifics of a particular computer card DT.
For example, how would a VGA output port be defined? Normally, there would be a connector node with an endpoint, so something like this in the housing DT, perhaps:
vga0: connector@0 { compatible = "vga-connector"; label = "vga";
port { vga_connector_in: endpoint { remote-endpoint = <&vga_out>; }; }; };
And I guess there could be a corresponding endpoint in the computer card DT that makes VGA output a possibility. There might also have to be some kind of ddc-i2c-bus attribute referencing a node elsewhere, too.
Sorry if this was discussed on the list or documented elsewhere!
[...]
I guess I should ask whether such support made it into either of them.
investigating 96boards and how their shields are supported should give some leads, there.
This was the first thing I found:
https://www.96boards.org/documentation/consumer/dragonboard/dragonboard410c/ guides/dt-overlays.md.html
But there is also this:
https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html
Oddly, the syntax in the above is far simpler than various other guides to overlays, making me wonder whether they are describing different kinds of overlays. For example (see part 2):
https://www.raspberrypi.org/documentation/configuration/device-tree.md
the absolute last thing needed however is hardcoded static compiled dtb, one for eoma68-a20-microdesktop, one for laptop, then one for eoma68-rk3288-microdesktop
it would be utterly disastrous for EOMA68 to consider the base dtb file to be a "chipset" level tree.
it has to be a *board* level (machine level) tree because of the standalone nature of EOMA68 Cards.
Yes, I think everyone understands this now, at least intuitively if not the precise mechanism. :-)
however all 68 pins are "shield" pins, *not* "machine" pins, and need to be dynamically connected just like for 96boards shields.
The mechanism, yes.
Paul
On Sunday, July 19, 2020, Paul Boddie paul@boddie.org.uk wrote:
The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT
has
a node ®_usb0_vbus that the other DTs do not have.
So, it seems possible that an updated DT file would be a minor
variation
on the Cubieboard 2 file.
pretty much.
I'll have to look at the OTG thing to figure out its significance.
if starting from a recent cubietruck dts, the interface (schematic) is exactly the same, so cut/paste is perfectly appropriate.
the 2 other USB ports are plain USB2 and go out on EOMA68 pins.
[...]
Indeed. I guess the computer card device tree sits at a level between
the
chipset device tree and what would normally be the machine device tree.
if i understand you correctly: not quite.
the closest equivalent is 96boards and arduino shield dtbs.
here the 96boards dtb file *is* the machine level.
the pin header dtb locations however are NOT FILLED IN.
they instead have special references - pointers. each pointer is named (given the pin number) but is set to NULL by default.
at RUNTIME - not "device tree compile time" - at **RUNTIME** - a special command is run with a "shield dtb fragment" that directly and DYNAMICALLY replaces those named parameter pointers with the reference to the dtb fragment.
I understood the run-time aspect, but I thought that the specialisation would be a bit like the way something like the Cubieboard DT specialises the A20 DT.
ah, yes.
So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or enables various peripherals,
so, some peripherals like the otg, mmc0, hdmi and also interestingly the 2 USB ports despite being on the EOMA68 connector, these would all go in the same level as cubietruck i.e. machine level.
and then - at run-time - each housing's DT which activates the peripherals that were exposed but not enabled.
yes. the 2nd sdmmc (mmc3 i think), the i2c, uart, spi, rgbttl and eint, all those would go into "dynamic pointer default NULL" set.
I guess the challenge is to describe the peripherals in a neutral way in the housing's DT so as not to taint them with the specifics of a particular computer card DT.
that's where the "shield" thing comes in.
For example, how would a VGA output port be defined?
that ie precisely what the dynamic thing does: it's specified in the dynamic fragment.
the dynamic fragment contains the names eoma68-pin1 to 68 and says that when eoma68-pin33 is connected it shall be given the purpose "RGBTTL HSYNC".
Normally, there would be a connector node with an endpoint, so something like this in the housing DT, perhaps:
vga0: connector@0 { compatible = "vga-connector"; label = "vga";
port { vga_connector_in: endpoint { remote-endpoint = <&vga_out>; }; };};
this definition would go in the *Housing* dtb fragment.
the vga_out is defined to contain *dynamic* connections which link HSYNC to eoma68-pin33 (whatever).
only when the "dynamic merge" kernel syscall is made will the substitutions occur, *including* the (now new) definition of vga0
events will then fire, the associated rgbttl.ko gets loaded, and (eventually) /dev/fb0 appears.
And I guess there could be a corresponding endpoint in the computer card DT that makes VGA output a possibility.
no: it really does go in the *Housing* dtb fragment.
There might also have to be some kind of ddc-i2c-bus attribute referencing a node elsewhere, too.
exactly. and one for mmc3, and one for SPI and uart. but all in the *fragment* not the main eoma68 board file.
all with pin definitions that are *only* connected up at runtime.
all of which reference the eoma68 pins.
note:
any developer that connects peripherals via external arduino circuits (breadboards) is on their own, here, although the process needs documenting.
a user connecting say an SPI Ethernet to the MicroDesktop header would need to start from the Microdesktop dts fragment, add the spi peripheral to it, the run the "dynamic dtb load" command.
i *hope* that they implemented "unload dynamic dtb" by now.
Sorry if this was discussed on the list or documented elsewhere!
a long time ago.
[...]
I guess I should ask whether such support made it into either of them.
investigating 96boards and how their shields are supported should give
some
leads, there.
This was the first thing I found:
https://www.96boards.org/documentation/consumer/ dragonboard/dragonboard410c/ guides/dt-overlays.md.html
ta-daaa that's it. overlays.
give me a sec to review the links
l.
On Monday, July 20, 2020, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
i *hope* that they implemented "unload dynamic dtb" by now.
Finally, if you need to remove all overlays in one-go, just call of_overlay_remove_all() which will remove every single one in the correct order.
it got implemented, thank goodness.
that means (hypothetically) that Cards can be powered from OTG, *unplugged live*, put into a *new housing* and not require a reboot.
ultimately some Cards might actually have small internal batteries or supercapacitors to keep running for long enough to transfer without external power.
cat tsys01.dtbo > /sys/kernel/config/device-tree/overlays/tsys01/dtbo
that looks pretty straightforward.
the rest is probably because the dragonboard was quite early, and now the docs are out of date
the rbpi doc looks pretty garbled. phandles. *that* was the name of the pointer thing i mentioned.
it doesn't help the person writing that document that the rbpi foundation actually changed the pinouts between versions of hardware, and of course everyone expects the old overlays to "just work".
this kind of hell is precisely why eoma68 will not be "upgraded". or if it is, it'll be "faster sdmmc" or "faster usb3" both of which do dynamic hardware-level runtime negotiation that has nothing to do with pinouts themselves.
i.e. there will *never* be "abandonment" of pinout definitions. a pin defined now as i2c-clk *will remain defined as such*, forever.
one minor complication with eoma68 is that all pins (except usb) are dual-purpose (GPIO) multiplexed however given that this is standard fare for shield headers i do not anticipate problems in the overlay fragment definitions.
l.
On Monday, 20 July 2020 01:38:34 CEST Luke Kenneth Casson Leighton wrote:
On Sunday, July 19, 2020, Paul Boddie paul@boddie.org.uk wrote:
So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or enables various peripherals,
so, some peripherals like the otg, mmc0, hdmi and also interestingly the 2 USB ports despite being on the EOMA68 connector, these would all go in the same level as cubietruck i.e. machine level.
Right.
and then - at run-time - each housing's DT which activates the peripherals that were exposed but not enabled.
yes. the 2nd sdmmc (mmc3 i think), the i2c, uart, spi, rgbttl and eint, all those would go into "dynamic pointer default NULL" set.
Yes, and I guess that the rgbttl peripheral would be the thing providing the VGA output, so there would potentially be something there with a device tree "port" that can connect to a corresponding port in the housing's DT...
[...]
For example, how would a VGA output port be defined?
that ie precisely what the dynamic thing does: it's specified in the dynamic fragment.
the dynamic fragment contains the names eoma68-pin1 to 68 and says that when eoma68-pin33 is connected it shall be given the purpose "RGBTTL HSYNC".
How does this correspond to the pinctrl groups that one usually sees? In the sun7i-a20.dtsi file there is a pinctrl node with lots of groups defined.
Would there be some kind of "logical" pin group like this...?
&pio { eoma68_lcd_pins: eoma68-lcd-pins { /* assuming that LCD0 pins are routed via the connector's LCD pins */ pins = "PD0", "PD1", ... ; function = "eoma68-lcd"; }; };
(Here, I used the sun7i-a20-olinuxino-micro.dts file to provide some hints. In the Ingenic DT files, by the way, you don't see so much of this any more because the groups are actually defined in the driver itself.)
And then, there would be something using this pin group. Here, I have to guess which phandle to use amongst other things. Since tcon0 is an A20 thing, this would be in the computer card DT, with other card DTs providing their own necessary recipes:
&tcon0 { ports { tcon0_lcd_out: port@2 { ... tcon0_out_lcd: endpoint@2 { ... remote-endpoint = <&vga_connector_in>; }; }; }; };
Here, I'm missing the mechanism by which the pin group gets selected. Some kind of coordination with the driver would be needed, I guess. Otherwise, it wouldn't know which mode to use so as to produce output on the LCD0 pins.
Normally, there would be a connector node with an endpoint, so something like this in the housing DT, perhaps:
vga0: connector@0 {
compatible = "vga-connector"; label = "vga"; port { vga_connector_in: endpoint { remote-endpoint = <&vga_out>; }; };};
this definition would go in the *Housing* dtb fragment.
Yes, in the housing DT.
the vga_out is defined to contain *dynamic* connections which link HSYNC to eoma68-pin33 (whatever).
only when the "dynamic merge" kernel syscall is made will the substitutions occur, *including* the (now new) definition of vga0 events will then fire, the associated rgbttl.ko gets loaded, and (eventually) /dev/fb0 appears.
Yes, I'm just missing some idea of the actual device tree plumbing. But then I don't think I'm particularly good at figuring out Linux device drivers and device trees.
Paul
On Monday, July 20, 2020, Paul Boddie paul@boddie.org.uk wrote:
Yes, and I guess that the rgbttl peripheral would be the thing providing the VGA output, so there would potentially be something there with a device tree "port" that can connect to a corresponding port in the housing's DT...
if we follow the idea put forward by the rbpi "hat" community, actually "VGA peripheral" or "SPI Ethernet peripheral" would be yet further separatw dtb fragments (overlays) that get dropped on top of a "Housing" overlay.
even the EOMA68 SDMMC interface could potentially have a "hat" file for a SD WIFI Card or other type of non-dynamically-detectable peripheral.
it gets complicated, pretty quickly, but this is kinda unavoidable.
part of my responsibility as the Cerification Mark holder is to maintain that database of overlay fragments and ensure that it is properly compliant and well documented.
[...]
For example, how would a VGA output port be defined?
that ie precisely what the dynamic thing does: it's specified in the dynamic fragment.
the dynamic fragment contains the names eoma68-pin1 to 68 and says that when eoma68-pin33 is connected it shall be given the purpose "RGBTTL
HSYNC".
How does this correspond to the pinctrl groups that one usually sees? In the sun7i-a20.dtsi file there is a pinctrl node with lots of groups defined.
the overlays *use* those pinctrl groups and basically limit them to a hard subset of functionality.
so for example, one set of pins routed to EOMA68 I2C *might* also be capable of supporting UART by a happy coincidence.
however despite this being possible it is NOT permitted to advertise that fact... and also claim EOMA68 Compliance.
to protect users who expect interoperability now and in 20 years time i have to drop a ton of bricks on anyone trying to say "oh yes, EOMA68 devices can do UART on the I2C pins" for example.
Would there be some kind of "logical" pin group like this...?
&pio { eoma68_lcd_pins: eoma68-lcd-pins { /* assuming that LCD0 pins are routed via the connector's LCD pins */ pins = "PD0", "PD1", ... ; function = "eoma68-lcd"; }; };
i would prefer a level of indirection that names the EOMA68 pins by numbers, these numbers to be nothing to do with the function
the reason being that exactly like pinctrl all EOMA68 Interface pins (except USB) can be GPIO.
then, just like pinctrl, the next layer drops overlays onto those 68 pins to provide LCD ... *if the Housing Manufacturer wants them to be LCD*.
if the Housing Manufacturer wants 15 pin RGBTTL not 24 pin RGBTTL that frees up quite a few pins in the EOMA68 RGBTTL bank for use as GPIO.
likewise SDMMC can operate in 1 pin mode, freeing up 3 other pins for GPIO.
these examples shows that it is therefore quite important to not drop functions directly onto pins but to have that "redirection" layer:
&pio { eoma68_pin0: { pins = "PD0" function = "eoma68-pin0"; }; eoma68_pin1: { pins = "PE5" function = "eoma68-pin1"; }; ..... ..... };
and *then* have an LCD dtb overlay (one 24, one 18, one 16 and one 15) which refers to the pins by their *EOMA68* name
NOT the pinctrl name (e.g. from sunxi a20 dts) which is SoC specific.
Here, I'm missing the mechanism by which the pin group gets selected.
the abstraction / indirection, explicitly naming the pins with EOMA68 pin names, i believe answers this.
Cards dtb files *provide* those 68 pins as named in the dtb file
Housing overlays *use* those 68 names.
Engineers using rbpi style Housings (such as the Microdesktop with its 20 pin header) drop "hat" overlays onto functions such as eoma68_spi or eoma68_i2c and so on.
Some
kind of coordination with the driver would be needed, I guess. Otherwise, it wouldn't know which mode to use so as to produce output on the LCD0 pins.
correct. this is what the I2C EEPROM is for.
it is the responsibility of uboot and the linux kernel to:
* read the EEPROM * determine the Housing type * load the correct dtb overlay
at that point the Card can automatically recognise the Housing, drivers load from there and users are happy. "Plug it in, it will just work" is satisfied.
of course, this means they need to regularly keep the dtb overlay database updated...
.
Yes, I'm just missing some idea of the actual device tree plumbing. But then I don't think I'm particularly good at figuring out Linux device drivers and device trees
it's all there. the pieces are in place. reading the I2C EEPROM however does need to be written.
alan cox suggested this be added to lib/eoma68 in the linux kernel source tree.
l.
Paul
On Tuesday, 21 July 2020 00:49:48 CEST Luke Kenneth Casson Leighton wrote:
i would prefer a level of indirection that names the EOMA68 pins by numbers, these numbers to be nothing to do with the function
the reason being that exactly like pinctrl all EOMA68 Interface pins (except USB) can be GPIO.
then, just like pinctrl, the next layer drops overlays onto those 68 pins to provide LCD ... *if the Housing Manufacturer wants them to be LCD*.
OK, so the housing DT will contain the following for a VGA port...
An actual connector definition for the benefit of various mechanisms. The reason why I keep mentioning this is because the DRM mechanisms seem to depend on it: there needs to be some kind of sink for the signal, and it's usually some kind of connector. But this is arguably the easy part.
Something that indicates the EOMA pin requirements to supply that connector. Normally, pin usage gets written on a specialisation of a device peripheral. For example, for the Ben NanoNote:
&lcd { pinctrl-names = "default"; pinctrl-0 = <&pins_lcd>;
port { panel_output: endpoint { remote-endpoint = <&panel_input>; }; }; };
But in the EOMA68 universe, we don't want to override a specific peripheral (&lcd here refers to the LCD controller on the JZ4720), nor do we want to indicate pins that are SoC-specific.
So, we can define some kind of mapping for pins in the computer card DT, just as you do here...
these examples shows that it is therefore quite important to not drop functions directly onto pins but to have that "redirection" layer:
&pio { eoma68_pin0: { pins = "PD0" function = "eoma68-pin0"; }; eoma68_pin1: { pins = "PE5" function = "eoma68-pin1"; }; ..... ..... };
and *then* have an LCD dtb overlay (one 24, one 18, one 16 and one 15) which refers to the pins by their *EOMA68* name
NOT the pinctrl name (e.g. from sunxi a20 dts) which is SoC specific.
But what I am missing is the construct by which you might apply the pin reservations, unless you are merely making aliases for platform-specific pin names within pinctrl and then using those in places where pinctrl attributes are used.
Specifically, what I wonder about is how the equivalent of the <&pins_lcd> gets applied at the SoC level given some kind of (platform-neutral) pin reservation in the housing DT.
Sorry if this is obvious, but without concrete DT syntax for the configuration throughout the different layers, I cannot see exactly how this would be done.
Paul
P.S. But recent experiences may be colouring my judgement here, having been trying to shake the box of existing drivers and DT fragments to try and persuade my CI20 to produce HDMI output, so far unsuccessfully. And yet, practically the same code produces a picture just fine when ported to L4Re, without all the distractions of driver frameworks and device trees (and the DRM stack testing modes over and over and over again).
On Tue, Jul 21, 2020 at 9:57 PM Paul Boddie paul@boddie.org.uk wrote:
OK, so the housing DT will contain the following for a VGA port...
paul: quite late, here, more tomorrow. summary strategy:
* look at rbpi "hats" and how dtb overlays are done * copy that * rename rbpi "hat" overlay pins 0 to M to "eoma68 pins 1 to 68"
in theory that should be pretty much the entire job, bar removing all multiplexed options other than the 1 specialist function and the GPIO option. where in rbpi base "hat" interface there would be up to 4 multiplexed options per pin (one of which will be GPIO), that must be restricted to "GPIO" and "EOMA68 function", per pin.
that really should be all.
l.
On Tuesday, 21 July 2020 23:25:12 CEST Luke Kenneth Casson Leighton wrote:
On Tue, Jul 21, 2020 at 9:57 PM Paul Boddie paul@boddie.org.uk wrote:
OK, so the housing DT will contain the following for a VGA port...
paul: quite late, here, more tomorrow. summary strategy:
- look at rbpi "hats" and how dtb overlays are done
- copy that
- rename rbpi "hat" overlay pins 0 to M to "eoma68 pins 1 to 68"
It would be useful to know where all these "hats" are defined. I found the following:
https://github.com/raspberrypi/linux/tree/rpi-5.4.y/arch/arm/boot/dts/overla...
A common theme seems to involve augmenting the gpio node from the chipset DT as follows (in the nicer syntax):
&gpio { some_pins: some_pins { brcm,pins = <...>; ... }; };
Then, various other nodes are augmented, also with device-specific details.
in theory that should be pretty much the entire job, bar removing all multiplexed options other than the 1 specialist function and the GPIO option. where in rbpi base "hat" interface there would be up to 4 multiplexed options per pin (one of which will be GPIO), that must be restricted to "GPIO" and "EOMA68 function", per pin.
that really should be all.
Sorry, I just don't see how the overlays I found do this generically. All the node referencing is device-specific, although there is some aliasing done in "the firmware" for a limited number of nodes.
That works just fine with things like Raspberry Pi, but what we really need to see is what a device tree overlay looks like for a product that is used on multiple devices without needing to be customised for each one, if such an overlay exists.
The only thing I've found that seems to do pin aliasing is this:
https://beagleboard.org/blog/2018-01-17-building-a-device-tree-overlay-for-y...
Even then, there is some pretty liberal usage of what appear to be device- specific node references alongside the pin aliases, but I guess it is a start.
Paul
On Tue, Jul 21, 2020 at 11:53 PM Paul Boddie paul@boddie.org.uk wrote:
On Tuesday, 21 July 2020 23:25:12 CEST Luke Kenneth Casson Leighton wrote:
On Tue, Jul 21, 2020 at 9:57 PM Paul Boddie paul@boddie.org.uk wrote:
OK, so the housing DT will contain the following for a VGA port...
paul: quite late, here, more tomorrow. summary strategy:
- look at rbpi "hats" and how dtb overlays are done
- copy that
- rename rbpi "hat" overlay pins 0 to M to "eoma68 pins 1 to 68"
It would be useful to know where all these "hats" are defined. I found the following:
https://github.com/raspberrypi/linux/tree/rpi-5.4.y/arch/arm/boot/dts/overla...
https://github.com/raspberrypi/linux/blob/rpi-5.4.y/arch/arm/boot/dts/overla...
they're merging the pull-up and setup functionality with the actual device itself. this completely defeats the object of the exercise.
that really should be all.
Sorry, I just don't see how the overlays I found do this generically.
if that IR example is anything to go by.
That works just fine with things like Raspberry Pi, but what we really need to see is what a device tree overlay looks like for a product that is used on multiple devices without needing to be customised for each one, if such an overlay exists.
The only thing I've found that seems to do pin aliasing is this:
https://beagleboard.org/blog/2018-01-17-building-a-device-tree-overlay-for-y...
yes, pin aliasing should do the trick. so instead of (as in the IR example)
brcm,pins = <18>; // pin 18 brcm,function = <0>; // in brcm,pull = <2>; // up
it would be
eoma68,pins = <18>; // pin 18 eoma68,function = <0>; // in eoma68,pull = <2>; // up
Even then, there is some pretty liberal usage of what appear to be device- specific node references alongside the pin aliases, but I guess it is a start.
indeed.
so what it looks like is, the beagleboard example shows how to "disable" pins (describes it as "get them back"). following that, if those pins can be cut/paste redefined and given eoma68 names, i believe we're good to go.
i believe it may be necessary to have two definitions for each pin, though (in each Card Overlay).
* one definition for the EOMA68 pin as a GPIO * one definition for the EOMA68 pin in its "function" capacity. SPI MOSI for example.
the "hats" then choose which of these to "group together" in order to create "EOMA68 SPI" or "EOMA68 LCD 15 pin bus" and so on.
l.
On Monday, 20 July 2020 00:56:19 CEST Paul Boddie wrote:
But there is also this:
https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html
Which had been removed when I just checked.
Oddly, the syntax in the above is far simpler than various other guides to overlays, making me wonder whether they are describing different kinds of overlays. For example (see part 2):
https://www.raspberrypi.org/documentation/configuration/device-tree.md
This is explained here:
https://source.android.com/devices/architecture/dto/syntax
Paul
On Sunday, 19 July 2020 13:17:38 CEST Pablo Rath wrote:
On Sat, Jul 18, 2020 at 07:19:37PM +0200, Paul Boddie wrote: I saw that there is a section about legacy U-Boot in the page:
http://rhombus-tech.net/allwinner/a20/EOMA68-A20_2-7-4_preproduction/
Yes, obviously I had to start with U-Boot first. Luke told me that sunxi U-Boot should build fine and that nothing has changed so I started there.
For mainline U-Boot I still need a valid config file to do 'make eoma68_foo_defconfig'. There is a .dts file here (http://rhombus-tech.net/allwinner/a20/boot/sun7i-a20-eoma68-a20.dts) but I don't know if it was used for mainline U-Boot and not just for Kernel compilation.
I'm not sure what the relationship is between U-Boot and Linux. My impression is that U-Boot borrows code from Linux, and there are benefits to U-Boot knowing about device tree files, but my own experiences with U-Boot development are rather limited.
[...]
So, what seems to be necessary is to get an older compiler and to use that instead. Since distributions retire older compilers regularly, I used Buildroot to create a suitable GCC 4.9 cross-compiler than can then build the legacy U-Boot.
I have realised that on Debian gcc versions are kept installed. I have a native armhf installation (initially installed with Jessie) currently upgraded to stretch and gcc-4.9 is still installed. Changed between gcc versions with 'update-alternatives'. I don't know if this also apllies to cross-toolchains because my experience with crossbuilding is limited.
Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages so this could be another solution I have not tested yes as I have no armhf sid installation.
It's useful to hear that GCC versions are kept around. Recently, I upgraded hardware and now have Debian Buster installed, and I think GCC 7 is about as old as the packages get. For cross-compilers, GCC 8 seems to be what is offered.
I did realise that you had probably managed just fine without having to find a toolchain, but it is probably useful to provide a path for others to follow as well.
[...]
This is extremly helpful. I am going to try it out. Can you copy that to the wiki? Maybe as a separate subpage or at the end. I think we should keep everything short and clear for those who know what they are doing but still provide enough hand-holding and external context for those with less experience.
I'll try and add the recipes to the wiki. I was going to do so, but then found myself doing other things instead.
[...]
Good news is that I made it to the sunxi U-Boot prompt on Friday. Booted via USB-FEL. So my soldered Pins, UART connection, Power Supply, µUSB-OTG on the card work fine.
Great!
Next I have planned to compile a sunxi 3.4 Kernel and debootstrap a Debian rootfs. Then I want to try mainline U-Boot and a mainline Kernel. Feel free to share your solutions and best practices with me!
I'll try and take another look at this today. Hopefully, the old code can still be built without too many obstacles. The mainline code might present some challenges, at least with regard to specific hardware support.
Paul
On Sun, Jul 19, 2020 at 1:30 PM Paul Boddie paul@boddie.org.uk wrote:
I'm not sure what the relationship is between U-Boot and Linux. My impression is that U-Boot borrows code from Linux,
yes. they basically borrow / forward-port (on an irregular basis) device driver code. combined with parts of libc6 (or uclibc), "executables" can be built with a minimum of fuss that look pretty much like standard c programs except that it's one entire static binary. imagine something like busybox combined with parts of the linux kernel into a single static in-memory binary and that's pretty much what it is.
l.
arm-netbook@lists.phcomp.co.uk
-
Christopher Havel -
Hendrik Boom -
Luke Kenneth Casson Leighton -
Pablo Rath -
Paul Boddie