U-Boot ARM Patches

The complete list of ARM custodians is at U-Boot Gatekeepers
This page is (mainly concerned) with patches regarding different ARM architectures and patches specific for the ARM Ltd supplied development boards

• Integrator/AP
• Integrator/CP
• VersatileAB
• VersatilePB
• RealViewEB
• RealViewPB

For other boards with ARM based processors see the U-Boot main list and board manufacturer's sites.

ARM U-Boot Repository

The ARM U-Boot repository can be cloned from git://www.denx.de/git/u-boot-arm.git e.g. :-

cg-clone git://www.denx.de/git/u-boot-arm.git

It contains patchs accepted by, but not yet pulled into, the mainline, for boards with ARM cores.

linux ARM Wiki U-Boot Repository Status

The u-boot-armdev repository on this, linux ARM, Wiki offers branches for

• New ARM supplied development boards
• New ARM architectures etc

which are awaiting testing before being accepted into other u-boot repositories, or may never be submitted to the generic u-boot.

---

The master branch will be kept up to date w.r.t the u-boot head, rather than git://www.denx.de/git/u-boot-arm.git.
The source code from http://www.arm.com/linux/linux_download.html should suffice for all current ARM supported development boards.
Please contact mailto:peter.pearsearm.com with any queries regarding that code.
The downloads are also available from http://www.linux-arm.org/git/ael.git under dated branches.

Branch name (Starts with date patch was posted)	Submitted by	Status	MAKEALL Run on arm/ ppc/ mips	Patch mail subject and/or comment
master	peter<dot>pearse<at>arm<dot>com	See below for patches awaiting pul		Based on U-Boot Main Repository
071107_mem	Andrea Marson <r&d2dave-tech.it>	Awaiting fix to remove kernel dependencies		ARM optimized memcpy/memmove routines Main u-boot has diverged sufficiently to make this unmaintainable - last successful patch attached
080212_options				Rationalize ARM cpu compiler options This branch merged into armdevCS branch
090204_armdev				This branch replaced by 090727_armdev If this gives you insurmountable problems please conatct peter.pearse<at>arm.com
090727_armdev	peter<dot>pearse<at>arm<dot>com	Ready for test	Yes	Provides patches for all currently supported, ARM supplied, development boards Many of these patches will eventually be individually moved upstream
090701_armdevCS				This branch replaced by 090728_armdevCS If this gives you insurmountable problems please conatct peter.pearse<at>arm.com
090728_armdevCS	peter<dot>pearse<at>arm<dot>com	Ready for test		Uses Code Sourcery toolchain, rather than ELDK Some parts make use of the latest ARM architecture(s) Based on the armdev branch
090703_mali				This branch replaced by 090728_mali If this gives you insurmountable problems please conatct peter.pearse<at>arm.com
090728_mali	peter<dot>pearse<at>arm<dot>com	Under construction		This branch is intended for U-Boot modifications specific to Mali development and testing on ARM supplied development boards Based on the armdevCS branch

next

New branches are often made available on the git before they are listed here

Patches Under Consideration

Now documented at www.denx.de/wiki/UBoot/

Patch Process

Now documented at www.denx.de/wiki/UBoot/

Additional notes re submitting patches using git and Evolution (I gave up on Outlook)

I've abandoned this and switched to using the Stacked Git mail commands.

Criteria for patch acceptance/rejection (not ordered)

Wolfgang's design principles
Please add suggestions at the end of this page

• Apply cleanly to the u-boot head
  
• Meet all requirements for patches, as detailed in uboot/README
  
• Patch should not break any existing code As tested by the MAKEALL utility.
  
• Apply the coding style described in the README , as checked by <linux kernel>scripts/check_patch.pl
  
• Be consistent with the README - where no README patch is applied.
  
• It's a boot-loader Not an operating system, general purpose utility, other. Unnecessary functionality should not be added.
  
• Loaded object size should not increase, unless justifiable.
  
• Speed of operation esp image load & boot should not increase, unless justifiable.
  
• U-Boot should be easy to use by end users, not developers.
  
• U-Boot should be easyto port Code complexity & excessive configuration to be avoided.
  
• If the user enters an address, that address can be made visible in a debugger
  This arises from the threads "Re: [U-Boot-Users] Atmel DataFlash hooks.", "Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK?" where it was originally argued that DataFlash (& possibly other storage media) should be treated as bus addressable memory.
• Adhere to the agreed directory structure More info here
• U-Boot standard input base is hex. Has always been that way. 0x is just a waste of key presses and memory footprint.
• No double check messages e.g. "Do you really want to do this?"
  "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn

Suggested Additional Criteria

Please feel free to add (polite) suggestions.

Outstanding Queries In the U-Boot Code

• Should data storage (e.g SPI, MMC, DataFlash, SD card) be accessible via "addressing"? - see e.g.
• Should U-Boot code move to GPLv3.0?

-- PeterPearse - 09 Feb 2007