[U-Boot-Users] AVR32 patchset available
Hi everyone,
I've created a stripped-down patchset for AVR32 which can be downloaded from http://avr32linux.org/patches/u-boot/1.1.4-hs1/. The various files there should be familiar to anyone who have used -mm versions of the Linux kernel. The various formats are also explained at http://avr32linux.org/twiki/bin/view/Main/UbootPatches
If anyone would take a look and tell me what you think should be done differently, I would be very grateful. Ulf, have you looked at the patches before? Do you have any comments?
I'll try to keep the patchset in sync with the latest u-boot git tree. Wolfgang, please merge whenever you feel like.
The patchset currently consists of
* make-3.81-build-fix.patch (already submitted to the list) * use-g-instead-of-gstabs.patch (ditto) * uimage-for-avr32.patch (ditto) * avr32-arch.patch (AVR32 architecture support) * at32ap-cpu.patch (Support for AVR32 AP CPUs, including AT32AP7000) * atmel-usart.patch (Driver for the AT91/AT32 USART -- I'll submit this for discussion in a moment) * atstk1000-board.patch (ATSTK1000/ATSTK1002 board support) * version.patch (version update, don't apply)
A more extensive description is included within each patch.
Please let me know if you want me to post the whole thing to the list. Two of the patches break the 40K size limit, so I'll have to compress them.
Combined diffstat below (excluding upstream.patch and version.patch).
Thanks,
Haavard
MAINTAINERS | 11 MAKEALL | 9 Makefile | 13 README | 18 - avr32_config.mk | 25 + board/atstk1000/Makefile | 58 +++ board/atstk1000/atstk1000.c | 54 +++ board/atstk1000/atstk1002.c | 32 + board/atstk1000/config.mk | 3 board/atstk1000/flash.c | 222 ++++++++++++ board/atstk1000/u-boot.lds.S | 79 ++++ cpu/at32ap/Makefile | 46 ++ cpu/at32ap/at32ap7000/Makefile | 42 ++ cpu/at32ap/at32ap7000/devices.c | 448 +++++++++++++++++++++++++ cpu/at32ap/at32ap7000/hebi.c | 38 ++ cpu/at32ap/config.mk | 22 + cpu/at32ap/cpu.c | 82 ++++ cpu/at32ap/dcache_clean.c | 40 ++ cpu/at32ap/dcache_invalidate.c | 38 ++ cpu/at32ap/device.c | 126 +++++++ cpu/at32ap/entry.S | 46 ++ cpu/at32ap/exception.c | 119 ++++++ cpu/at32ap/hsdramc.c | 155 ++++++++ cpu/at32ap/hsdramc1.h | 157 ++++++++ cpu/at32ap/hsmc3.h | 156 ++++++++ cpu/at32ap/pio.c | 94 +++++ cpu/at32ap/pio2.h | 172 +++++++++ cpu/at32ap/pm.c | 158 ++++++++ cpu/at32ap/sm.h | 240 +++++++++++++ cpu/at32ap/start.S | 113 ++++++ drivers/Makefile | 2 drivers/atmel_usart.c | 95 +++++ drivers/atmel_usart.h | 320 +++++++++++++++++ examples/Makefile | 4 examples/stubs.c | 13 include/asm-avr32/addrspace.h | 46 ++ include/asm-avr32/arch-at32ap7000/hmatrix2.h | 388 +++++++++++++++++++++ include/asm-avr32/arch-at32ap7000/memory-map.h | 61 +++ include/asm-avr32/arch-at32ap7000/platform.h | 146 ++++++++ include/asm-avr32/bitops.h | 25 + include/asm-avr32/byteorder.h | 37 ++ include/asm-avr32/cacheflush.h | 83 ++++ include/asm-avr32/dma-mapping.h | 64 +++ include/asm-avr32/errno-base.h | 60 +++ include/asm-avr32/errno.h | 121 ++++++ include/asm-avr32/global_data.h | 59 +++ include/asm-avr32/initcalls.h | 45 ++ include/asm-avr32/io.h | 105 +++++ include/asm-avr32/posix_types.h | 145 ++++++++ include/asm-avr32/processor.h | 96 +++++ include/asm-avr32/ptrace.h | 148 ++++++++ include/asm-avr32/sdram.h | 33 + include/asm-avr32/sections.h | 40 ++ include/asm-avr32/setup.h | 153 ++++++++ include/asm-avr32/string.h | 28 + include/asm-avr32/sysreg.h | 274 +++++++++++++++ include/asm-avr32/types.h | 84 ++++ include/asm-avr32/u-boot.h | 56 +++ include/configs/atstk1002.h | 186 ++++++++++ lib_avr32/Makefile | 46 ++ lib_avr32/avr32_linux.c | 179 +++++++++ lib_avr32/board.c | 193 ++++++++++ lib_avr32/cache.c | 28 + lib_avr32/dma-alloc.c | 51 ++ lib_avr32/interrupts.c | 39 ++ lib_avr32/memset.S | 82 ++++ lib_avr32/tagtable.h | 177 +++++++++ lib_avr32/time.c | 86 ++++ 68 files changed, 6610 insertions(+), 4 deletions(-)
Dear Haarvard,
in message 20060831140349.524b989d@cad-250-152.norway.atmel.com you wrote:
I've created a stripped-down patchset for AVR32 which can be downloaded from http://avr32linux.org/patches/u-boot/1.1.4-hs1/. The various files there should be familiar to anyone who have used -mm versions of the Linux kernel. The various formats are also explained at http://avr32linux.org/twiki/bin/view/Main/UbootPatches
Ummm.. I assume that http://avr32linux.org/patches/u-boot/1.1.4-hs1/u-boot-1.1.4-hs1.patch.bz2 contains everything, right?
If anyone would take a look and tell me what you think should be done differently, I would be very grateful. Ulf, have you looked at the patches before? Do you have any comments?
Yes, please read the README, and follow the rules given there.
Then check your patch. What I see is only garbage that cannot be applied at all:
-> patch -s -p1 --dry-run </tmp/u-boot-1.1.4-hs1.patch 14 out of 15 hunks FAILED -- saving rejects to file CHANGELOG.rej Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] n 3 out of 3 hunks ignored -- saving rejects to file CREDITS.rej Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] n 6 out of 6 hunks ignored -- saving rejects to file MAINTAINERS.rej Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] n 11 out of 11 hunks ignored -- saving rejects to file MAKEALL.rej Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] n 37 out of 37 hunks ignored -- saving rejects to file Makefile.rej 5 out of 13 hunks FAILED -- saving rejects to file README.rej The next patch would create the file blackfin_config.mk, which already exists! Assume -R? [n] n Apply anyway? [n] n 1 out of 1 hunk ignored -- saving rejects to file blackfin_config.mk.rej The next patch would create the file board/BuS/EB+MCF-EV123/EB+MCF-EV123.c, which already exists! Assume -R? [n] n Apply anyway? [n] n 1 out of 1 hunk ignored -- saving rejects to file board/BuS/EB+MCF-EV123/EB+MCF-EV123.c.rej The next patch would create the file board/BuS/EB+MCF-EV123/Makefile, which already exists! Assume -R? [n] n Apply anyway? [n] n 1 out of 1 hunk ignored -- saving rejects to file board/BuS/EB+MCF-EV123/Makefile.rej The next patch would create the file board/BuS/EB+MCF-EV123/VCxK.c, which already exists! Assume -R? [n] n Apply anyway? [n] n 1 out of 1 hunk ignored -- saving rejects to file board/BuS/EB+MCF-EV123/VCxK.c.rej The next patch would create the file board/BuS/EB+MCF-EV123/VCxK.h, which already exists! Assume -R? [n] n Apply anyway? [n] n 1 out of 1 hunk ignored -- saving rejects to file board/BuS/EB+MCF-EV123/VCxK.h.rej The next patch would create the file board/BuS/EB+MCF-EV123/cfm_flash.c, which already exists! Assume -R? [n] n Apply anyway? [n] n 1 out of 1 hunk ignored -- saving rejects to file board/BuS/EB+MCF-EV123/cfm_flash.c.rej The next patch would create the file board/BuS/EB+MCF-EV123/cfm_flash.h, which already exists! Assume -R? [n] n Apply anyway? [n] n 1 out of 1 hunk ignored -- saving rejects to file board/BuS/EB+MCF-EV123/cfm_flash.h.rej The next patch would create the file board/BuS/EB+MCF-EV123/config.mk, which already exists! Assume -R? [n] n Apply anyway? [n] n ...
The patch might have been built against an ancient version of the software - this is of no use.
Sorry.
Best regards,
Wolfgang Denk
On Thu, 31 Aug 2006 14:38:45 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Haarvard,
in message 20060831140349.524b989d@cad-250-152.norway.atmel.com you wrote:
I've created a stripped-down patchset for AVR32 which can be downloaded from http://avr32linux.org/patches/u-boot/1.1.4-hs1/. The various files there should be familiar to anyone who have used -mm versions of the Linux kernel. The various formats are also explained at http://avr32linux.org/twiki/bin/view/Main/UbootPatches
Ummm.. I assume that http://avr32linux.org/patches/u-boot/1.1.4-hs1/u-boot-1.1.4-hs1.patch.bz2 contains everything, right?
Well, everything and more, actually. It also contains "upstream.patch" which is everything between U-Boot 1.1.4 and the git head I rebased against.
Sorry I forgot to mention that. It's explained on the UbootPatches page I mentioned, though.
If anyone would take a look and tell me what you think should be done differently, I would be very grateful. Ulf, have you looked at the patches before? Do you have any comments?
Yes, please read the README, and follow the rules given there.
Uh...could you please be more specific? I know some of the patches are too large, but it's hard to split them up any further. I thought I'd keep them off the list to avoid bothering people who don't really care about the AVR32 port, but I can of course post them if you want me to.
The only other things I can think about are CHANGELOG and CREDITS entries, although the Subject: line in each patch should be suitable for the changelog, no?
The patch might have been built against an ancient version of the software - this is of no use.
Indeed. But you really shouldn't apply the "combined" patch -- I intended that one for people who want to test stuff without having to figure out the exact git state I made the patchset against.
Also, as I mentioned in the previous mail, some of the patches have been submitted before, and some should not be applied at all. Here are the patches you may want consider:
http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/avr32-arch.patch http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/at32ap-cpu.patch http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/atmel-usart.patch http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/atstk1000-board.pa...
These patches are all on mbox format, so if you want to merge them into a git branch for testing, simply feed them to git-am.
If you want me to combine these patches into a single package, please let me know.
Sorry for the noise.
Haavard
Dear Haarvard,
in message 20060831150308.22fdbab7@cad-250-152.norway.atmel.com you wrote:
Yes, please read the README, and follow the rules given there.
Uh...could you please be more specific? I know some of the patches are too large, but it's hard to split them up any further. I thought I'd keep them off the list to avoid bothering people who don't really care about the AVR32 port, but I can of course post them if you want me to.
I mean the Coding Style rules; a cursory scan showed at least incorrect indentation (not by 8 characters, by space instead of TAB) in several files (cpu/at32ap/dcache_clean.c, cpu/at32ap/dcache_invalidate.c, and include/asm-avr32/posix_types.h) and trailing empty lines in some (include/asm-avr32/sections.h and include/asm-avr32/setup.h).
Some files look pretty odd and should be cleaned up; for example:
"cpu/at32ap/pio2.h": ... 40 /* Bitfields in PER */ 41 42 /* Bitfields in PDR */ 43 44 /* Bitfields in PSR */ 45 46 /* Bitfields in OER */ 47 48 /* Bitfields in ODR */ 49 50 /* Bitfields in OSR */ 51 52 /* Bitfields in IFER */ 53 54 /* Bitfields in IFDR */ 55 56 /* Bitfields in ISFR */ 57 58 /* Bitfields in SODR */ 59 60 /* Bitfields in CODR */ 61 62 /* Bitfields in ODSR */ 63 64 /* Bitfields in PDSR */ 65 66 /* Bitfields in IER */ 67 68 /* Bitfields in IDR */ 69 70 /* Bitfields in IMR */ 71 72 /* Bitfields in ISR */ 73 74 /* Bitfields in MDER */ 75 76 /* Bitfields in MDDR */ 77 78 /* Bitfields in MDSR */ 79 80 /* Bitfields in PUDR */ 81 82 /* Bitfields in PUER */ 83 84 /* Bitfields in PUSR */ 85 86 /* Bitfields in ASR */ 87 88 /* Bitfields in BSR */ 89
Get rid of this.
90 /* Bitfields in ABSR */ 91 #define PIO2_P0_OFFSET 0 92 #define PIO2_P0_SIZE 1 93 #define PIO2_P1_OFFSET 1 94 #define PIO2_P1_SIZE 1 95 #define PIO2_P2_OFFSET 2 96 #define PIO2_P2_SIZE 1 97 #define PIO2_P3_OFFSET 3 98 #define PIO2_P3_SIZE 1 99 #define PIO2_P4_OFFSET 4 100 #define PIO2_P4_SIZE 1 101 #define PIO2_P5_OFFSET 5 102 #define PIO2_P5_SIZE 1 103 #define PIO2_P6_OFFSET 6 104 #define PIO2_P6_SIZE 1 105 #define PIO2_P7_OFFSET 7 106 #define PIO2_P7_SIZE 1 107 #define PIO2_P8_OFFSET 8 108 #define PIO2_P8_SIZE 1 109 #define PIO2_P9_OFFSET 9 110 #define PIO2_P9_SIZE 1 111 #define PIO2_P10_OFFSET 10 112 #define PIO2_P10_SIZE 1 113 #define PIO2_P11_OFFSET 11 114 #define PIO2_P11_SIZE 1 115 #define PIO2_P12_OFFSET 12 116 #define PIO2_P12_SIZE 1 117 #define PIO2_P13_OFFSET 13 118 #define PIO2_P13_SIZE 1 119 #define PIO2_P14_OFFSET 14 120 #define PIO2_P14_SIZE 1 121 #define PIO2_P15_OFFSET 15 122 #define PIO2_P15_SIZE 1 123 #define PIO2_P16_OFFSET 16 124 #define PIO2_P16_SIZE 1 125 #define PIO2_P17_OFFSET 17 ... etc.
This just makes to code difficult to read and understand. Please cleanup.
The same applies to other files as well.
Please get rid of include/asm-avr32/errno-base.h and use justerrno.h like other architectures do.
Your global data structure contains a field "jt". Please add comment what it's needed for.
Please get rid of include/asm-avr32/initcalls.h
The only other things I can think about are CHANGELOG and CREDITS entries, although the Subject: line in each patch should be suitable for the changelog, no?
Special formatting is required for the CHANGELOG entry.
The patch might have been built against an ancient version of the software - this is of no use.
Indeed. But you really shouldn't apply the "combined" patch -- I intended that one for people who want to test stuff without having to figure out the exact git state I made the patchset against.
That's what I did. I just used the latest version.
Also, as I mentioned in the previous mail, some of the patches have been submitted before, and some should not be applied at all. Here are the patches you may want consider:
http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/avr32-arch.patch http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/at32ap-cpu.patch http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/atmel-usart.patch http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/atstk1000-board.pa...
See comments above. Please clean up and resubmit on the mailing list.
If you want me to combine these patches into a single package, please let me know.
No, please stick to the rules as speicfied in the README.
Best regards,
Wolfgang Denk
On Thu, 31 Aug 2006 16:06:56 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Haarvard,
in message 20060831150308.22fdbab7@cad-250-152.norway.atmel.com you wrote:
Yes, please read the README, and follow the rules given there.
Uh...could you please be more specific? I know some of the patches are too large, but it's hard to split them up any further. I thought I'd keep them off the list to avoid bothering people who don't really care about the AVR32 port, but I can of course post them if you want me to.
I mean the Coding Style rules; a cursory scan showed at least incorrect indentation (not by 8 characters, by space instead of TAB) in several files (cpu/at32ap/dcache_clean.c, cpu/at32ap/dcache_invalidate.c, and include/asm-avr32/posix_types.h) and trailing empty lines in some (include/asm-avr32/sections.h and include/asm-avr32/setup.h).
Ah, I guess I have to check my setup. Both git and quilt are supposed to catch things like this...
Some files look pretty odd and should be cleaned up; for example:
"cpu/at32ap/pio2.h":
Yup, that's an autogenerated file. I'll give them an overhaul.
88 /* Bitfields in BSR */ 89Get rid of this.
Will do.
90 /* Bitfields in ABSR */ 91 #define PIO2_P0_OFFSET 0 92 #define PIO2_P0_SIZE 1
... etc.This just makes to code difficult to read and understand. Please cleanup.
I agree, they don't make much sense for the PIO controller, and they aren't really used anyway, so I'll just get rid of them.
The same applies to other files as well.
Ok, I'll clean up the register definition headers.
Please get rid of include/asm-avr32/errno-base.h and use justerrno.h like other architectures do.
Ok, will do.
Your global data structure contains a field "jt". Please add comment what it's needed for.
I haven't got the faintest clue what it's needed for, but all architectures have got one. I'll add a comment saying "jump table".
Please get rid of include/asm-avr32/initcalls.h
Where should I move the prototypes?
Actually, I see there are a couple of prototypes that aren't needed in the current patchset. I'll remove them as well.
The only other things I can think about are CHANGELOG and CREDITS entries, although the Subject: line in each patch should be suitable for the changelog, no?
Special formatting is required for the CHANGELOG entry.
Documented where?
The patch might have been built against an ancient version of the software - this is of no use.
Indeed. But you really shouldn't apply the "combined" patch -- I intended that one for people who want to test stuff without having to figure out the exact git state I made the patchset against.
That's what I did. I just used the latest version.
There's a newer version than 1.1.4?
Also, as I mentioned in the previous mail, some of the patches have been submitted before, and some should not be applied at all. Here are the patches you may want consider:
http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/avr32-arch.patch http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/at32ap-cpu.patch http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/atmel-usart.patch http://avr32linux.org/patches/u-boot/1.1.4-hs1/broken-out/atstk1000-board.pa...
See comments above. Please clean up and resubmit on the mailing list.
Ok, I'll do that. Thanks for taking the time to review it.
If you want me to combine these patches into a single package, please let me know.
No, please stick to the rules as speicfied in the README.
I take it you think the current division is fine, then?
Thanks,
Haavard
Dear Haarvard,
in message 20060831163957.6bb7f388@cad-250-152.norway.atmel.com you wrote:
Ah, I guess I have to check my setup. Both git and quilt are supposed to catch things like this...
How did you set it up to catch thse things?
Please get rid of include/asm-avr32/initcalls.h
Where should I move the prototypes?
I think they are used in board.c only?
Special formatting is required for the CHANGELOG entry.
Documented where?
Use the existing CHANGELOG as an example.
That's what I did. I just used the latest version.
There's a newer version than 1.1.4?
Of course: top of tree in git.
I take it you think the current division is fine, then?
I didn't look for this. You will have to resplit anyway due to the 40kB size limit on the list.
Best regards,
Wolfgang Denk
On Thu, 31 Aug 2006 16:53:22 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Haarvard,
in message 20060831163957.6bb7f388@cad-250-152.norway.atmel.com you wrote:
Ah, I guess I have to check my setup. Both git and quilt are supposed to catch things like this...
How did you set it up to catch thse things?
For git, there are .git/hooks/pre-applypatch and .git/hooks/pre-commit. But they don't seem to catch the spaces-instead-of-tabs case...
For quilt, I guess I was thinking about the --strip-trailing-whitespace option to quilt refresh. Which obviously doesn't catch this either...
I suppose the git hooks can be modified to catch spaces-instead-of-tabs too, I'll have a go at it.
Please get rid of include/asm-avr32/initcalls.h
Where should I move the prototypes?
I think they are used in board.c only?
Yes, but they are implemented elsewhere. And IMHO keeping the prototypes in a header file is the easiest way to ensure the prototypes are in sync with the actual implementation.
Special formatting is required for the CHANGELOG entry.
Documented where?
Use the existing CHANGELOG as an example.
Ok.
I take it you think the current division is fine, then?
I didn't look for this. You will have to resplit anyway due to the 40kB size limit on the list.
All the patches fit within the 40k size limit if I compress them. If you don't have any other objections, I'll keep the current division.
Haavard
participants (2)
-
Haavard Skinnemoen -
Wolfgang Denk