[U-Boot] Re-introducing support for OLD hardware
Good day all
I am currently faced with a task of having to run new software on ageing hardware. We have currently about 1000 units in the field of a machine that runs Windows CE using the Samsung S3C6410.
Because these are considerable assets its not a simple case of replacing them with new, more modern hardware.
The goal is to be able to get these existing boards to run Ubuntu so that we can run GoLang applications, so we need the GUI with just a relatively recent browser.
The board in question is a near perfect clone of the SMDK6410, which was supported fully in U-boot in the past, indeed I can select SMDK6410 and compile a working U-boot using 1.3.4 sources
After much effort I managed to get a tailored (tailored as in having changed the memory configuration to match the hardware) U-boot V1.3.4 compiled and running for this chip, the problem now, obviously we have a fairly recent Linux kernel compiled and it won't boot because the Device Tree Blob doesn't exist on such an old version of U-boot.
So my questions are:
- Has anyone perhaps created a branch or fork of the current or nearly current version of U-boot and patched in this support. I see a lot of Chinese websites where they seem to have done this but the language barrier is a big problem. Also a lot of dead links are another problem.
- If there isn't something out there, would it be possible to run through the steps with me to add support for this CPU again. I don't mind doing the work, the main issue is I have no clue how U-boot actually works internally.
I have FULL JTAG access to this board, with a perfectly functional OpenOCD setup. This is how we are able to program versions of U-boot into the FLASH.
Hoping someone can assist
Kindest Regards, Jason Mitchell Software Developer Spark ATM Systems (PTY) LTD
On Thu, Apr 12, 2018 at 09:04:20AM +0200, Jason Mitchell wrote:
Good day all
I am currently faced with a task of having to run new software on ageing hardware. We have currently about 1000 units in the field of a machine that runs Windows CE using the Samsung S3C6410.
Because these are considerable assets its not a simple case of replacing them with new, more modern hardware.
The goal is to be able to get these existing boards to run Ubuntu so that we can run GoLang applications, so we need the GUI with just a relatively recent browser.
The board in question is a near perfect clone of the SMDK6410, which was supported fully in U-boot in the past, indeed I can select SMDK6410 and compile a working U-boot using 1.3.4 sources
After much effort I managed to get a tailored (tailored as in having changed the memory configuration to match the hardware) U-boot V1.3.4 compiled and running for this chip, the problem now, obviously we have a fairly recent Linux kernel compiled and it won't boot because the Device Tree Blob doesn't exist on such an old version of U-boot.
So my questions are:
- Has anyone perhaps created a branch or fork of the current or nearly
current version of U-boot and patched in this support. I see a lot of Chinese websites where they seem to have done this but the language barrier is a big problem. Also a lot of dead links are another problem.
- If there isn't something out there, would it be possible to run through
the steps with me to add support for this CPU again. I don't mind doing the work, the main issue is I have no clue how U-boot actually works internally.
I have FULL JTAG access to this board, with a perfectly functional OpenOCD setup. This is how we are able to program versions of U-boot into the FLASH.
There's two options: 1) You can re-introduce support for the SMDK6410 into mainline U-Boot and be an active maintainer of it. It was removed due to lack of active maintainers.
2) You can, for Linux, use the "appended DTB" work-around to boot a modern kernel from an old bootloader.
Hi there Thanks for the advice.
The DTP append work-around sounds like a horrible hack that might come to bite me later, so I am going to rather go with re-introducing SMDK6410 back into the U-boot and maintain it. The benefits are then of course that we will be retrofitting something modern in the field, as opposed to a loader that is 7 years old.
I will clone the current mainline and start investigating how to best approach this.
Thanks and Regards, Jason Mitchell
On 12 April 2018 at 16:01, Tom Rini trini@konsulko.com wrote:
On Thu, Apr 12, 2018 at 09:04:20AM +0200, Jason Mitchell wrote:
Good day all
I am currently faced with a task of having to run new software on ageing hardware. We have currently about 1000 units in the field of a machine
that
runs Windows CE using the Samsung S3C6410.
Because these are considerable assets its not a simple case of replacing them with new, more modern hardware.
The goal is to be able to get these existing boards to run Ubuntu so that we can run GoLang applications, so we need the GUI with just a relatively recent browser.
The board in question is a near perfect clone of the SMDK6410, which was supported fully in U-boot in the past, indeed I can select SMDK6410 and compile a working U-boot using 1.3.4 sources
After much effort I managed to get a tailored (tailored as in having changed the memory configuration to match the hardware) U-boot V1.3.4 compiled and running for this chip, the problem now, obviously we have a fairly recent Linux kernel compiled and it won't boot because the Device Tree Blob doesn't exist on such an old version of U-boot.
So my questions are:
- Has anyone perhaps created a branch or fork of the current or nearly
current version of U-boot and patched in this support. I see a lot of Chinese websites where they seem to have done this but the language
barrier
is a big problem. Also a lot of dead links are another problem.
- If there isn't something out there, would it be possible to run through
the steps with me to add support for this CPU again. I don't mind doing
the
work, the main issue is I have no clue how U-boot actually works
internally.
I have FULL JTAG access to this board, with a perfectly functional
OpenOCD
setup. This is how we are able to program versions of U-boot into the
FLASH.
There's two options:
- You can re-introduce support for the SMDK6410 into mainline U-Boot
and be an active maintainer of it. It was removed due to lack of active maintainers.
- You can, for Linux, use the "appended DTB" work-around to boot a
modern kernel from an old bootloader.
-- Tom
Hi everyone.
In regards to re-introduction and ongoing maintenance of support for old SoC, we have determined that this would be a futile effort. More so when you consider that the team here wanted to run Jquery and all of the newer frameworks on this old SoC.
We have therefore chosen to support a "current" SoC in our design, using the AllWinner H3 series, and for this reason I will remain on the mailing list.
Since this will be a deployment of U-boot in a secure environment with rather strict rules and regulations, we will probably have to maintain our own internal fork of U-Boot mainine. The reason for this is we wish to add our own proprietary functionality to lock out Linux kernels and images that we do not control. I haven't looked at this in great detail yet, so if I am trying to reinvent the wheel please let me know. The idea is simple- we want the board to refuse to boot any build of Linux we didn't compile ourselves. This is to comply with Payment Card Industry rules.
This will mean I will have to pick up new releases and ensure interoperability with whatever is current.
Many Thanks Jason Mitchell
On 12 April 2018 at 16:01, Tom Rini trini@konsulko.com wrote:
On Thu, Apr 12, 2018 at 09:04:20AM +0200, Jason Mitchell wrote:
Good day all
I am currently faced with a task of having to run new software on ageing hardware. We have currently about 1000 units in the field of a machine
that
runs Windows CE using the Samsung S3C6410.
Because these are considerable assets its not a simple case of replacing them with new, more modern hardware.
The goal is to be able to get these existing boards to run Ubuntu so that we can run GoLang applications, so we need the GUI with just a relatively recent browser.
The board in question is a near perfect clone of the SMDK6410, which was supported fully in U-boot in the past, indeed I can select SMDK6410 and compile a working U-boot using 1.3.4 sources
After much effort I managed to get a tailored (tailored as in having changed the memory configuration to match the hardware) U-boot V1.3.4 compiled and running for this chip, the problem now, obviously we have a fairly recent Linux kernel compiled and it won't boot because the Device Tree Blob doesn't exist on such an old version of U-boot.
So my questions are:
- Has anyone perhaps created a branch or fork of the current or nearly
current version of U-boot and patched in this support. I see a lot of Chinese websites where they seem to have done this but the language
barrier
is a big problem. Also a lot of dead links are another problem.
- If there isn't something out there, would it be possible to run through
the steps with me to add support for this CPU again. I don't mind doing
the
work, the main issue is I have no clue how U-boot actually works
internally.
I have FULL JTAG access to this board, with a perfectly functional
OpenOCD
setup. This is how we are able to program versions of U-boot into the
FLASH.
There's two options:
- You can re-introduce support for the SMDK6410 into mainline U-Boot
and be an active maintainer of it. It was removed due to lack of active maintainers.
- You can, for Linux, use the "appended DTB" work-around to boot a
modern kernel from an old bootloader.
-- Tom
On Thu, 12 Apr 2018 09:04:20 +0200 Jason Mitchell jason@sparkatm.co.za wrote:
Good day all
I am currently faced with a task of having to run new software on ageing hardware. We have currently about 1000 units in the field of a machine that runs Windows CE using the Samsung S3C6410.
Because these are considerable assets its not a simple case of replacing them with new, more modern hardware.
The goal is to be able to get these existing boards to run Ubuntu so that we can run GoLang applications, so we need the GUI with just a relatively recent browser.
The board in question is a near perfect clone of the SMDK6410, which was supported fully in U-boot in the past, indeed I can select SMDK6410 and compile a working U-boot using 1.3.4 sources
After much effort I managed to get a tailored (tailored as in having changed the memory configuration to match the hardware) U-boot V1.3.4 compiled and running for this chip, the problem now, obviously we have a fairly recent Linux kernel compiled and it won't boot because the Device Tree Blob doesn't exist on such an old version of U-boot.
So my questions are:
- Has anyone perhaps created a branch or fork of the current or nearly
current version of U-boot and patched in this support. I see a lot of Chinese websites where they seem to have done this but the language barrier is a big problem. Also a lot of dead links are another problem.
- If there isn't something out there, would it be possible to run
through the steps with me to add support for this CPU again. I don't mind doing the work, the main issue is I have no clue how U-boot actually works internally.
I have FULL JTAG access to this board, with a perfectly functional OpenOCD setup. This is how we are able to program versions of U-boot into the FLASH.
Hoping someone can assist
If this helps - I do have some code (including OpenOCD restoration/debricking files) to add support for smdk6410 based on v2013.04 u-boot.
As fair as I remember this code was booting till prompt, but was NOT in a shape allowing mainlining.
Unfortunately, I don't have smdk6410 dev board anymore, so I cannot help with testing/tunning the HW.
Kindest Regards, Jason Mitchell Software Developer Spark ATM Systems (PTY) LTD _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
participants (3)
-
Jason Mitchell -
Lukasz Majewski -
Tom Rini