Jump to content

U-Boot C2 baud rate


mboehmer

Recommended Posts

Hi,

 

I'm working on adding baudrate changes to recent Uboot v2017.11 for the Odroid C2. Took some time to understand the way Uboot handles access to hardware...

I tried to get some clean solution, and wanted to ask on how I can submit my changes to the main developpers.

 

Would be great if you could give me a hint on that issue.

 

I still need some time for testing the changes, so it is not urgent (we need this feature to have 9600 8N1 access to the C2, as it will be deployed on a place without easy access :)

 

So far, Michael

Link to comment
Share on other sites

Thanks for the link :)

I will try to follow instruction, but usually I'm struggling with git or cvs stuff... in case I will ask for assistance.

Somehow doing low level programming seems to be much easier than using git correctly :)

 

First question is: I use the ARMBIAN build stuff (with ./compile.sh), which is always fetching current source of the GIT. If I create a fork, how can I get compile.sh (which is doing a great job, indeed, it works like a charm) to use that fork instead of the main branch?

 

Michael

Link to comment
Share on other sites

10 hours ago, mboehmer said:

Somehow doing low level programming seems to be much easier than using git correctly :)

 

:P  I did assembly coding on hardware with tens of bytes of RAM, and I agree.

 

 

As for the sources, in your clone of the repo:

 

./build/config/sources/<name_of_board>

 

 

Link to comment
Share on other sites

Sounds like a Pico8 (did assembler there) or similar - yes, I usually do VHDL programming, but C is fine for me, as long as we stay in simple hardware environments :) with no cvs or GIT involved...

 

Maybe my question was not clear: up to now, I used the standard Xenial 16.04 build environment, and simply made a "./compile.sh" to get an eMMC image (or some errors...).

With a new fork on GitHub, I can't do that, as the compile script will get the sources of the main branch. So far, I made changes in the git clone of that build environment, and git a patch file with all my changes included. I prefer to stay within that build script as long as possible, as I have no time (and no nerves) to start learning yet another cross compiler orgy (did that on the MCM4+16 from Axis years ago and still hate it...).

 

So maybe I get things finished and will apply my patches in my fork in the end.

Sorry for asking so many stupid questions :(

 

Michael

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines