Re: [U-Boot] [PATCH 1/2 V3] at91sam9261ek: make operational again
Hi Reinhard, + * lockup during boot due to an overlap in the BSS segment. So, we choose a + * safe load adress to begin with, namely 0x20a0 + */ +#define CONFIG_SYS_TEXT_BASE 0x20a0 I'd recommend setting this to the very beginning of SDRAM(0x2000), note that initial SP and GD would be put into SRAM further down. The SRAM is used by the LCD controller. So, we cannot use it for the SP and GD. +/* Define actual evaluation board type from used processor type */ #ifdef CONFIG_AT91SAM9G10EK #define CONFIG_AT91SAM9G10 1 /* It's an Atmel AT91SAM9G10 SoC*/ #else #define CONFIG_AT91SAM9261 1 /* It's an Atmel AT91SAM9261 SoC*/ That looks to me the other way: its defining the processor type from the board type. If both boards are identical but for the processor, the processor should be defined in boards.cfg, like it is for 9260/9xe-ek. This patch was originally meant for mainstream in the first place. It was not meant to make it cleaner, just to make it compile and work again. The other patch was meant to make it cleaner according to your rework and redesigns. #define CONFIG_NR_DRAM_BANKS 1 -#define PHYS_SDRAM 0x2000 -#define PHYS_SDRAM_SIZE 0x0400 /* 64 megs */ +#define CONFIG_SYS_SDRAM_BASE 0x2000 +#define CONFIG_SYS_SDRAM_SIZE 0x0400 /* 64 megs */ It is up to you, but (64 20) might look nicer. This is more a matter of taste I think. I will see what I do with it. +/* size in bytes reserved for initial data */ +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000 \ + - GENERATED_GBL_DATA_SIZE) I've put that into SRAM, that facilitates future NOR flash boot variants where SDRAM would be initialized by low level it... See LCD remark. AT91SAM9261_UHP_BASE */ #ifdef CONFIG_AT91SAM9G10EK -#define CONFIG_SYS_USB_OHCI_SLOT_NAME at91sam9g10 +#define CONFIG_SYS_USB_OHCI_SLOT_NAME at91sam9g10 #else -#define CONFIG_SYS_USB_OHCI_SLOT_NAME at91sam9261 +#define CONFIG_SYS_USB_OHCI_SLOT_NAME at91sam9261 #endif Could we not use ATMEL_CPU_NAME here? Its capitalized, but I assume that would not matter? Can be done. please merge move of at91sam9261 to boards.cfg from Patch 2/2 here, this patch could IMHO still go into v2011.03; Patch 2/2 are changes for u-boot-atmel/rework2011xxx branch ... Reinhard do you agree? In theory, yes, it could be considered a bug fix. But whats the point of this double effort? Its easier when both patches are merged together and applied to top of rework. Well, I would prefer if this patch goes to mainline as soon as possible. I use this board to test the OHCI and USB-CDC stuff in the u-boot-usb tree. Your rework tree seems to be pending since november 2010, and I have no clear view when that is going to mainline. So, since this board is broken in mainline it is bothering my work as U-boot USB custodian. So, do you have any objections if I would do the cleanups and improvements in the 2/2 patch? Can you please push this patch upstream as it is? Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot - USB to Ethernet patch
Hi Simon, 2011/2/18 Simon Glass s...@chromium.org: +UBML Hi Anders, You will need at least: /* Enable USB Ethernet dongles */ #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX (and your platform must support USB with CONFIG_CMD_USB and CONFIG_USB_EHCI for example) You will also want to enable the network commands: #define CONFIG_CMD_NET #define CONFIG_NET_MULTI #define CONFIG_CMD_PING #define CONFIG_CMD_DHCP and some bootp options: #define CONFIG_BOOTP_SUBNETMASK #define CONFIG_BOOTP_GATEWAY #define CONFIG_BOOTP_HOSTNAME #define CONFIG_BOOTP_BOOTPATH #define CONFIG_IPADDR 10.0.0.2 #define CONFIG_SERVERIP 10.0.0.1 #define CONFIG_BOOTFILE uImage I might have missed something, but that should be enough to make progress. 'usb start' should identify the Ethernet dongle. Then 'bootp' should use it to obtain an IP address from DHCP. Apparently it is not clear to others how it should be used. Can you please add a description to doc/README.usb and provide a patch for that? Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/15] ATMEL rework
Hi Reinhard, 2011/2/18 Reinhard Meyer u-b...@emk-elektronik.de: These are all the reworks on the ATMEL parts done by me so far. They are now officially posted as patches for commenting. They are the patches found in u-boot-atmel so far, with minor whitespace and long line fixes complained about by checkpatch. The following files are affected: (Output of git-diff-tree --stat HEAD~15 HEAD~0) arch/arm/cpu/arm926ejs/at91/Makefile | 1 + arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c | 47 +--- arch/arm/cpu/arm926ejs/at91/clock.c | 8 +- arch/arm/cpu/arm926ejs/at91/cpu.c | 11 +- arch/arm/cpu/arm926ejs/at91/eflash.c | 16 +- arch/arm/cpu/arm926ejs/at91/led.c | 2 +- arch/arm/cpu/arm926ejs/at91/reset.c | 4 +- arch/arm/cpu/arm926ejs/at91/timer.c | 37 ++-- arch/arm/include/asm/arch-at91/at91_common.h | 3 +- arch/arm/include/asm/arch-at91/at91_pio.h | 19 +-- arch/arm/include/asm/arch-at91/at91_rstc.h | 25 -- arch/arm/include/asm/arch-at91/at91sam9260.h | 252 ++-- .../arm/include/asm/arch-at91/at91sam9260_matrix.h | 102 - arch/arm/include/asm/arch-at91/at91sam9261.h | 187 --- arch/arm/include/asm/arch-at91/at91sam9263.h | 218 - arch/arm/include/asm/arch-at91/at91sam9g45.h | 225 +- arch/arm/include/asm/arch-at91/gpio.h | 18 +- arch/arm/include/asm/arch-at91/hardware.h | 96 +++- arch/arm/include/asm/arch-at91/io.h | 43 arch/arm/include/asm/arch-at91/memory-map.h | 36 --- drivers/gpio/at91_gpio.c | 54 +++-- drivers/mmc/gen_atmel_mci.c | 2 +- drivers/net/macb.c | 14 +- drivers/rtc/at91sam9_rtt.c | 14 +- drivers/serial/atmel_usart.c | 28 +-- drivers/spi/atmel_dataflash_spi.c | 94 +--- drivers/spi/atmel_spi.c | 16 +- drivers/usb/host/ohci-at91.c | 18 +- Patches for the usb drivers should go through the u-boot-usb custodian tree. But for this series it is okay if you push it forward. Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Albert ARIBAUD albert.arib...@free.fr writes: Le 18/02/2011 16:16, Raghuveer Murthy a écrit : U-boot built for MeeGo on PandaBoard, with compiler option -mfloat-abi=hard, caused a build break. Please refer to the bug id: http://bugs.meego.com/show_bug.cgi?id=13140 Is this the official U-Boot? Why is it still at 2010.09 ? Removing the -msoft-float options in the config.mk files, allowed it to be built for both armv7hl and armv7el compilers on MeeGo Please refer to the below link for more details: http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal Signed-off-by: Raghuveer Murthyraghuveer.mur...@ti.com I would like to know which board of mainline U-boot is affected by the issue and how I can reproduce it on u-boot[-arm]/master. I saw this for a while when building for Beagle. It no longer occurs with mainline u-boot. I can't say which commit fixed it. However, I can already tell that this 'bug' can only occur upon a mix of object files compiled with -msoft-float and -mhard-float; which means some files were compiled with -mhard-float; and this should not happen at all, since U-Boot should not use any floats at all, so: The problem was that something from libgcc got pulled in, probably an integer division or similar. - either some files in the case reported were compiled voluntarily with hard-float, and this is not a generally supported use case of U-Boot; - or they were compiled without any float option and the toolchain defaulted to hard-float, which may be a meego but is no reason in itself for U-Boot to adapt to it. In my case, it was the latter cause. My feeling at the moment is that U-Boot should keep -msoft-float, to be sure that any float code present in the code base, if it has to be, will run regardless of hw floating point capabilities, because U-Boot binaries should make the least possible assumptions on the hardware they are running on. Now, CPUs/SoCs/boards that know they have a floating point unit may justly want to replace -msoft-float with -mhard-float everywhere throughout U-Boot; I would welcome a patch that allows U-Boot to default to soft float while allowing CPUs/SoCs/boards to override it for hard float. In no case, however, should -msoft-float be *removed*: that would make float support in U-Boot implicit and dependent on the toolchain in use, and I think U-Boot float support should always be explicit and not depend on the toolchain. There is no reason for supporting hardware floating-point in u-boot. If floating-point is used at all, and I can't think of a place where it is, it is not relevant to performance. The added complexity of supporting a hardware FPU is not worth it, in my opinion. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Hello, Am 19.02.2011 12:19, schrieb Måns Rullgård: In no case, however, should -msoft-float be *removed*: that would make float support in U-Boot implicit and dependent on the toolchain in use, and I think U-Boot float support should always be explicit and not depend on the toolchain. There is no reason for supporting hardware floating-point in u-boot. If floating-point is used at all, and I can't think of a place where it is, it is not relevant to performance. The added complexity of supporting a hardware FPU is not worth it, in my opinion. I still don't understand this discussion. Floats aren't used in u-boot, so why should it make a difference if -msoft-float will be removed? I know there was one bug which linked in something wrong from glibc, but if that flag isn't needed than it shouldn't make a difference at all if -msoft-float or -mhard-float is used. So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Alexander Holler hol...@ahsoftware.de writes: Hello, Am 19.02.2011 12:19, schrieb Måns Rullgård: In no case, however, should -msoft-float be *removed*: that would make float support in U-Boot implicit and dependent on the toolchain in use, and I think U-Boot float support should always be explicit and not depend on the toolchain. There is no reason for supporting hardware floating-point in u-boot. If floating-point is used at all, and I can't think of a place where it is, it is not relevant to performance. The added complexity of supporting a hardware FPU is not worth it, in my opinion. I still don't understand this discussion. Floats aren't used in u-boot, so why should it make a difference if -msoft-float will be removed? I know there was one bug which linked in something wrong from glibc, but if that flag isn't needed than it shouldn't make a difference at all if -msoft-float or -mhard-float is used. The linker refuses to combine objects with different calling conventions, and those tags are set based only on compiler flags, not what code the file actually contains. Some version of u-boot with some versions of gcc erroneously pull in something from libgcc, which will fail if libgcc and u-boot used different ABI flags. The real error here is that of linking in libgcc in the first place, not the ABI flags. So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) I guess it's there to make sure no floating-point instructions make it into u-boot, even though floats are not used in the code. Perhaps someone was paranoid. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Le 19/02/2011 14:25, Måns Rullgård a écrit : So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) I guess it's there to make sure no floating-point instructions make it into u-boot, even though floats are not used in the code. Perhaps someone was paranoid. I think also that there is no choice but to have a float option for ARM C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with the 'soft' calling conventions), because the C compiler does not allow 'no floats', and anyway the C language *requires* to have some sort of float support. Actually if you don't specify any float option, the C toolchain will choose one, which is just the same in the end: *some* float option is chosen. And since some option must be chosen, I prefer that U-Boot make the explicit decision, and choose soft float for the reasons I already exposed. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Am 19.02.2011 14:51, schrieb Albert ARIBAUD: Le 19/02/2011 14:25, Måns Rullgård a écrit : So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) I guess it's there to make sure no floating-point instructions make it into u-boot, even though floats are not used in the code. Perhaps someone was paranoid. I think also that there is no choice but to have a float option for ARM C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with the 'soft' calling conventions), because the C compiler does not allow 'no floats', and anyway the C language *requires* to have some sort of float support. As it is on every platform. Actually if you don't specify any float option, the C toolchain will choose one, which is just the same in the end: *some* float option is chosen. Every compiler has dozens of options which are set to a default value. And since some option must be chosen, I prefer that U-Boot make the explicit decision, and choose soft float for the reasons I already exposed. I don't see any reason to explicitly set an option for something which isn't used, but I know of many reasons to avoid such. ;) Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Le 19/02/2011 15:06, Alexander Holler a écrit : Am 19.02.2011 14:51, schrieb Albert ARIBAUD: Le 19/02/2011 14:25, Måns Rullgård a écrit : So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) I guess it's there to make sure no floating-point instructions make it into u-boot, even though floats are not used in the code. Perhaps someone was paranoid. I think also that there is no choice but to have a float option for ARM C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with the 'soft' calling conventions), because the C compiler does not allow 'no floats', and anyway the C language *requires* to have some sort of float support. As it is on every platform. Indeed. Actually if you don't specify any float option, the C toolchain will choose one, which is just the same in the end: *some* float option is chosen. Every compiler has dozens of options which are set to a default value. Granted. But not all of them relate to hardware which may or may not be available. And since some option must be chosen, I prefer that U-Boot make the explicit decision, and choose soft float for the reasons I already exposed. I don't see any reason to explicitly set an option for something which isn't used, but I know of many reasons to avoid such. ;) At least there is one reason for having -msoft-float even though no floating point should be used in U-Boot : it helps catching cases where some code in U-Boot tries to use hard float. :) Think of it as choosing the least dangerous of Charybdis and Scylla, while trying our best not to get near any of the two. Regards, Alexander Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Albert ARIBAUD albert.arib...@free.fr writes: Le 19/02/2011 15:06, Alexander Holler a écrit : Am 19.02.2011 14:51, schrieb Albert ARIBAUD: Le 19/02/2011 14:25, Måns Rullgård a écrit : So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) I guess it's there to make sure no floating-point instructions make it into u-boot, even though floats are not used in the code. Perhaps someone was paranoid. I think also that there is no choice but to have a float option for ARM C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with the 'soft' calling conventions), because the C compiler does not allow 'no floats', and anyway the C language *requires* to have some sort of float support. As it is on every platform. Indeed. Actually if you don't specify any float option, the C toolchain will choose one, which is just the same in the end: *some* float option is chosen. Every compiler has dozens of options which are set to a default value. Granted. But not all of them relate to hardware which may or may not be available. And since some option must be chosen, I prefer that U-Boot make the explicit decision, and choose soft float for the reasons I already exposed. I don't see any reason to explicitly set an option for something which isn't used, but I know of many reasons to avoid such. ;) At least there is one reason for having -msoft-float even though no floating point should be used in U-Boot : it helps catching cases where some code in U-Boot tries to use hard float. :) There is one further complication here. If the compiler was built with -mfpu=neon as default, it might emit neon instructions for pure integer code. For the purpose of this discussion, such instructions should still be regarded as floating-point since they are tied to the VFP. Such code generation is disabled by -msoft-float. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Am 19.02.2011 15:27, schrieb Albert ARIBAUD: Le 19/02/2011 15:06, Alexander Holler a écrit : Am 19.02.2011 14:51, schrieb Albert ARIBAUD: Le 19/02/2011 14:25, Måns Rullgård a écrit : So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) I don't see any reason to explicitly set an option for something which isn't used, but I know of many reasons to avoid such. ;) At least there is one reason for having -msoft-float even though no floating point should be used in U-Boot : it helps catching cases where some code in U-Boot tries to use hard float. :) Think of it as choosing the least dangerous of Charybdis and Scylla, while trying our best not to get near any of the two. Hmm, I could argue exactly the oposite. When using -msoft-float you won't find (unwanted) usages of float on any platform. To follow your argument, hard-floats should be enabled (if possible), so the usage of floats would lead to an error (at least on platforms without support for that). ;) Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Le 19/02/2011 15:34, Måns Rullgård a écrit : Albert ARIBAUDalbert.arib...@free.fr writes: Le 19/02/2011 15:06, Alexander Holler a écrit : Am 19.02.2011 14:51, schrieb Albert ARIBAUD: Le 19/02/2011 14:25, Måns Rullgård a écrit : So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) I guess it's there to make sure no floating-point instructions make it into u-boot, even though floats are not used in the code. Perhaps someone was paranoid. I think also that there is no choice but to have a float option for ARM C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with the 'soft' calling conventions), because the C compiler does not allow 'no floats', and anyway the C language *requires* to have some sort of float support. As it is on every platform. Indeed. Actually if you don't specify any float option, the C toolchain will choose one, which is just the same in the end: *some* float option is chosen. Every compiler has dozens of options which are set to a default value. Granted. But not all of them relate to hardware which may or may not be available. And since some option must be chosen, I prefer that U-Boot make the explicit decision, and choose soft float for the reasons I already exposed. I don't see any reason to explicitly set an option for something which isn't used, but I know of many reasons to avoid such. ;) At least there is one reason for having -msoft-float even though no floating point should be used in U-Boot : it helps catching cases where some code in U-Boot tries to use hard float. :) There is one further complication here. If the compiler was built with -mfpu=neon as default, it might emit neon instructions for pure integer code. For the purpose of this discussion, such instructions should still be regarded as floating-point since they are tied to the VFP. Such code generation is disabled by -msoft-float. Thanks for indicating this. If I paraphrase this correctly, some toochains would generate floating instructions for integer if both -mfloat-abi=hard and -fmpu=neon were specified or were the default. I don't see this as a worrying matter though, because I suspect that toolchains that have -mfpu=neon will have -mfloat-abi=hard as well and target cpus that have hw floating point capabilities, where such float instructions would cause no problem. And it is not as if the C code used floats. Besides, so far I have seen no complaint that -msoft-float disabling -mfpu=neon causes any problem with U-Boot, so I suspect no board requires it now. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Hello, Am 19.02.2011 16:32, schrieb Albert ARIBAUD: Granted :) -- the best option would be to have -float-abi=none, but that does not exist, and I prefer to be sure that if some poor soul puts floating point code in U-Boot then at least it is going to work for all platforms, so I'll keep -msoft-float in here. Hmm, but as we've seen, that doesn't work for all platforms because you can't mix softfloat and hardfloat. So using softfloat breaks building on (default-) hardfloat platforms if some poor soul puts floating point code in (which requires hardfloat-libraries too). So I still think going with the default option would be the right way to go. ;) Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reading from NAND
After some experimenting the only issue that I have now is trying to
do an itest on a non-aligned byte. I get an alignment exception if I
test a non-word aligned bype. Is there a way to do a bitwise AND so
that I can read a word and mask out the byte that I am interested in?
Also does the shell support adding values like itest *(${base} +
${offset}) == 0x01?
Thanks,
David
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] reasons for armv5 as default
Am 19.02.2011 16:40, schrieb Alexander Holler: Hello, Am 19.02.2011 16:32, schrieb Albert ARIBAUD: Granted :) -- the best option would be to have -float-abi=none, but that does not exist, and I prefer to be sure that if some poor soul puts floating point code in U-Boot then at least it is going to work for all platforms, so I'll keep -msoft-float in here. Hmm, but as we've seen, that doesn't work for all platforms because you can't mix softfloat and hardfloat. So using softfloat breaks building on (default-) hardfloat platforms if some poor soul puts floating point code in (which requires hardfloat-libraries too). So I still think going with the default option would be the right way to go. ;) Btw, while we are there, is there any reason, besides being carefull, why u-boot for arm is compiled with -march=armv5(te) by default? I'm just curious if there are some reasons for not using march=amrv7a for armv7 platforms and don't want to start a discussion about removing that default. I've seen some comments about armv5, e.g. in arch/arm/cpu/armv7/omap3/cache.S, but I'm missing the knowledge to understand them. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cfb_console: fix RLE bitmap drawing code
There seems to be tools producing incorrect 'end of bitmap data'
markers '0100' in a RLE bitmap. Drawing such bitmaps can result
in overwriting memory above the frame buffer. E.g. on MPC5121e
based boards this memory can contain U-Boot environment.
We may not rely on the correct end of bitmap data marker 0001
only, but also have to check whether we are going to draw a
valid frame buffer scan line.
The patch provides a simple fix by checking the row index:
we finish the drawing if the row index becomes negative.
Reported-by: Michael Weiss michael.we...@ifm.com
Signed-off-by: Anatolij Gustschin ag...@denx.de
Tested-by: Anatolij Gustschin ag...@denx.de
---
drivers/video/cfb_console.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 3d047f2..599ebdb 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -938,7 +938,10 @@ static int display_rle8_bitmap (bmp_image_t *img, int
xoff, int yoff,
/* scan line end marker */
bm += 2;
x = 0;
- y--;
+ if (--y 0) {
+ decode = 0;
+ continue;
+ }
fbp = (unsigned char *)
((unsigned int)video_fb_address +
(((y + yoff) * VIDEO_COLS) +
@@ -952,6 +955,10 @@ static int display_rle8_bitmap (bmp_image_t *img, int
xoff, int yoff,
/* run offset marker */
x += bm[2];
y -= bm[3];
+ if (y 0) {
+ decode = 0;
+ continue;
+ }
fbp = (unsigned char *)
((unsigned int)video_fb_address +
(((y + yoff) * VIDEO_COLS) +
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH ATMEL REWORK][V3] update arm/at91rm9200 work with rework rework110202
* convert at91rm9200ek and eb_cpux9k2 board to ATMEL_xxx name scheme
* Fix: timer.c compile error io.h not found with arm/at91rm9200
* update arm920t/at91 to ATMEL_xxx name scheme
* update arm920t/at91 soc lib
* update at91_emac driver
Signed-off-by: Jens Scharsig js_at...@scharsoft.de
---
Changes since V2 whith space fix
arch/arm/cpu/arm920t/at91/reset.c |2 +-
arch/arm/cpu/arm920t/at91/timer.c | 12 +-
arch/arm/include/asm/arch-at91/at91_mc.h| 12 +-
arch/arm/include/asm/arch-at91/at91_pmc.h | 10 +-
arch/arm/include/asm/arch-at91/at91rm9200.h | 209 ++-
board/BuS/eb_cpux9k2/cpux9k2.c | 52
board/atmel/at91rm9200ek/at91rm9200ek.c |4 +-
board/atmel/at91rm9200ek/led.c | 22 ++--
drivers/net/at91_emac.c | 32 ++--
include/configs/at91rm9200ek.h |5 +-
include/configs/eb_cpux9k2.h| 23 ++--
11 files changed, 196 insertions(+), 187 deletions(-)
diff --git a/arch/arm/cpu/arm920t/at91/reset.c
b/arch/arm/cpu/arm920t/at91/reset.c
index 51043ec..4fa0f98 100644
--- a/arch/arm/cpu/arm920t/at91/reset.c
+++ b/arch/arm/cpu/arm920t/at91/reset.c
@@ -42,7 +42,7 @@ void __attribute__((weak)) board_reset(void)
void reset_cpu(ulong ignored)
{
- at91_st_t *st = (at91_st_t *) AT91_ST_BASE;
+ at91_st_t *st = (at91_st_t *) ATMEL_BASE_ST;
#if defined(CONFIG_AT91RM9200_USART)
/*shutdown the console to avoid strange chars during reset */
serial_exit();
diff --git a/arch/arm/cpu/arm920t/at91/timer.c
b/arch/arm/cpu/arm920t/at91/timer.c
index d9a024f..f0ad7d6 100644
--- a/arch/arm/cpu/arm920t/at91/timer.c
+++ b/arch/arm/cpu/arm920t/at91/timer.c
@@ -32,7 +32,7 @@
#include common.h
-#include asm/arch/io.h
+#include asm/io.h
#include asm/arch/hardware.h
#include asm/arch/at91_tc.h
#include asm/arch/at91_pmc.h
@@ -44,11 +44,11 @@ DECLARE_GLOBAL_DATA_PTR;
int timer_init(void)
{
- at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
- at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE;
+ at91_tc_t *tc = (at91_tc_t *) ATMEL_BASE_TC;
+ at91_pmc_t *pmc = (at91_pmc_t *) ATMEL_BASE_PMC;
/* enables TC1.0 clock */
- writel(1 AT91_ID_TC0, pmc-pcer); /* enable clock */
+ writel(1 ATMEL_ID_TC0, pmc-pcer); /* enable clock */
writel(0, tc-bcr);
writel(AT91_TC_BMR_TC0XC0S_NONE | AT91_TC_BMR_TC1XC1S_NONE |
@@ -96,14 +96,14 @@ void __udelay(unsigned long usec)
void reset_timer_masked(void)
{
/* reset time */
- at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
+ at91_tc_t *tc = (at91_tc_t *) ATMEL_BASE_TC;
gd-lastinc = readl(tc-tc[0].cv) 0x;
gd-tbl = 0;
}
ulong get_timer_raw(void)
{
- at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
+ at91_tc_t *tc = (at91_tc_t *) ATMEL_BASE_TC;
u32 now;
now = readl(tc-tc[0].cv) 0x;
diff --git a/arch/arm/include/asm/arch-at91/at91_mc.h
b/arch/arm/include/asm/arch-at91/at91_mc.h
index acfbd10..e0d1320 100644
--- a/arch/arm/include/asm/arch-at91/at91_mc.h
+++ b/arch/arm/include/asm/arch-at91/at91_mc.h
@@ -23,12 +23,12 @@
#ifndef AT91_MC_H
#define AT91_MC_H
-#define AT91_ASM_MC_EBI_CSA(AT91_MC_BASE + 0x60)
-#define AT91_ASM_MC_EBI_CFG(AT91_MC_BASE + 0x64)
-#define AT91_ASM_MC_SMC_CSR0 (AT91_MC_BASE + 0x70)
-#define AT91_ASM_MC_SDRAMC_MR (AT91_MC_BASE + 0x90)
-#define AT91_ASM_MC_SDRAMC_TR (AT91_MC_BASE + 0x94)
-#define AT91_ASM_MC_SDRAMC_CR (AT91_MC_BASE + 0x98)
+#define AT91_ASM_MC_EBI_CSA(ATMEL_BASE_MC + 0x60)
+#define AT91_ASM_MC_EBI_CFG(ATMEL_BASE_MC + 0x64)
+#define AT91_ASM_MC_SMC_CSR0 (ATMEL_BASE_MC + 0x70)
+#define AT91_ASM_MC_SDRAMC_MR (ATMEL_BASE_MC + 0x90)
+#define AT91_ASM_MC_SDRAMC_TR (ATMEL_BASE_MC + 0x94)
+#define AT91_ASM_MC_SDRAMC_CR (ATMEL_BASE_MC + 0x98)
#ifndef __ASSEMBLY__
diff --git a/arch/arm/include/asm/arch-at91/at91_pmc.h
b/arch/arm/include/asm/arch-at91/at91_pmc.h
index fb8bb17..086cb9b 100644
--- a/arch/arm/include/asm/arch-at91/at91_pmc.h
+++ b/arch/arm/include/asm/arch-at91/at91_pmc.h
@@ -17,11 +17,11 @@
#ifndef AT91_PMC_H
#define AT91_PMC_H
-#defineAT91_ASM_PMC_MOR(AT91_PMC_BASE + 0x20)
-#defineAT91_ASM_PMC_PLLAR (AT91_PMC_BASE + 0x28)
-#defineAT91_ASM_PMC_PLLBR (AT91_PMC_BASE + 0x2c)
-#define AT91_ASM_PMC_MCKR (AT91_PMC_BASE + 0x30)
-#define AT91_ASM_PMC_SR(AT91_PMC_BASE + 0x68)
+#defineAT91_ASM_PMC_MOR(ATMEL_BASE_PMC + 0x20)
+#defineAT91_ASM_PMC_PLLAR (ATMEL_BASE_PMC + 0x28)
+#defineAT91_ASM_PMC_PLLBR (ATMEL_BASE_PMC + 0x2c)
+#define AT91_ASM_PMC_MCKR (ATMEL_BASE_PMC + 0x30)
+#define AT91_ASM_PMC_SR(ATMEL_BASE_PMC + 0x68)
#ifndef __ASSEMBLY__
diff --git a/arch/arm/include/asm/arch-at91/at91rm9200.h
b/arch/arm/include/asm/arch-at91/at91rm9200.h
index 1bee6f2..19ad7f4
Re: [U-Boot] [PATCH ATMEL REWORK][V2] update arm/at91rm9200 work with rework rework110202
Am 11.02.2011 21:13, schrieb Wolfgang Denk: Dear Reinhard Meyer, In message 4d5597a8.9050...@emk-elektronik.de you wrote: Dear Wolfgang Denk, Dear Jens Scharsig, In message4d5573ca.9000...@scharsoft.de you wrote: * convert at91rm9200ek and eb_cpux9k2 board to ATMEL_xxx name scheme * Fix: timer.c compile error io.h not found with arm/at91rm9200 * update arm920t/at91 to ATMEL_xxx name scheme * update arm920t/at91 soc lib * update at91_emac driver ... /* Port B */ -#define AT91_PMX_BA_ERXCK 0x0008 -#define AT91_PMX_BA_ECOL 0x0004 -#define AT91_PMX_BA_ERXDV 0x0002 -#define AT91_PMX_BA_ERX3 0x0001 -#define AT91_PMX_BA_ERX2 0x8000 ^^^ Please, no space before tabs Those lines that are being removed by the patch. Oops. I marked the wrong line. I meant this one: - checkpatch ~/Mail/U-Boot/3377 WARNING: please, no space before tabs #379: FILE: arch/arm/include/asm/arch-at91/at91rm9200.h:112: +#define ATMEL_PMX_BA_ERX2 ^I0x8000$ Best regards, Wolfgang Denk I don't know, why my checkpatch version does not report this. But I have fix this in V3 of the Patch. Best regards, Jens Scharsig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] reasons for armv5 as default
Le 19/02/2011 16:59, Alexander Holler a écrit : Am 19.02.2011 16:40, schrieb Alexander Holler: Hello, Am 19.02.2011 16:32, schrieb Albert ARIBAUD: Granted :) -- the best option would be to have -float-abi=none, but that does not exist, and I prefer to be sure that if some poor soul puts floating point code in U-Boot then at least it is going to work for all platforms, so I'll keep -msoft-float in here. Hmm, but as we've seen, that doesn't work for all platforms because you can't mix softfloat and hardfloat. So using softfloat breaks building on (default-) hardfloat platforms if some poor soul puts floating point code in (which requires hardfloat-libraries too). You're missing the fact that floating point code is a no-no in U-Boot. We're not talking about the best option to support floating-point code in U-Boot, but the best option to catch the use of floating point. However, as I've said, I would be fine with someone submitting a patch that makes -mfloat-abi=xxx and -mfpu=yyy available as configuration options so that a board maintainer who feels the irresistible urge to have hard float support can have it *for performance improvement only* (as in the case Måns described about integer code being performed with float instructions), not for explicit use of floats or doubles in the code. Note that with such a scheme, a board (or SoC, or [vendor-specific] cpu) maintainer could even override the float default and decide to leave it blank so that the toolchain default is used, if they so want. The only things that won't be an option if such a patch is submitted are that i) the default config setting for float must be soft-float, and ii) a doc/README.arm-float must be added to reflect how the option works and what the risks are of soft and hard float, and that So I still think going with the default option would be the right way to go. ;) Btw, while we are there, is there any reason, besides being carefull, why u-boot for arm is compiled with -march=armv5(te) by default? I'm just curious if there are some reasons for not using march=amrv7a for armv7 platforms and don't want to start a discussion about removing that default. I've seen some comments about armv5, e.g. in arch/arm/cpu/armv7/omap3/cache.S, but I'm missing the knowledge to understand them. IIRC the conclusion was that U-Boot does not need armv7 specific instructions and besides, not all toolchains frequently used with U-Boot have v7 support -- especially the toolchain coming with ELDK 4.2. Regards, Alexander Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to use board specific #defines during building of linker script
On Thursday, February 17, 2011 16:52:14 Graeme Russ wrote: But why not just include config.h when building u-boot.lds? why not include it yourself ? #include config.h ive been doing this for years in the Blackfin arch (long before preprocessing the linker script was considered fashionable). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Albert ARIBAUD albert.arib...@free.fr writes: Le 19/02/2011 15:34, Måns Rullgård a écrit : Albert ARIBAUDalbert.arib...@free.fr writes: Le 19/02/2011 15:06, Alexander Holler a écrit : Am 19.02.2011 14:51, schrieb Albert ARIBAUD: Le 19/02/2011 14:25, Måns Rullgård a écrit : So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) I guess it's there to make sure no floating-point instructions make it into u-boot, even though floats are not used in the code. Perhaps someone was paranoid. I think also that there is no choice but to have a float option for ARM C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with the 'soft' calling conventions), because the C compiler does not allow 'no floats', and anyway the C language *requires* to have some sort of float support. As it is on every platform. Indeed. Actually if you don't specify any float option, the C toolchain will choose one, which is just the same in the end: *some* float option is chosen. Every compiler has dozens of options which are set to a default value. Granted. But not all of them relate to hardware which may or may not be available. And since some option must be chosen, I prefer that U-Boot make the explicit decision, and choose soft float for the reasons I already exposed. I don't see any reason to explicitly set an option for something which isn't used, but I know of many reasons to avoid such. ;) At least there is one reason for having -msoft-float even though no floating point should be used in U-Boot : it helps catching cases where some code in U-Boot tries to use hard float. :) There is one further complication here. If the compiler was built with -mfpu=neon as default, it might emit neon instructions for pure integer code. For the purpose of this discussion, such instructions should still be regarded as floating-point since they are tied to the VFP. Such code generation is disabled by -msoft-float. Thanks for indicating this. If I paraphrase this correctly, some toochains would generate floating instructions for integer if both -mfloat-abi=hard and -fmpu=neon were specified or were the default. -mfloat-abi of hard or softfp both allow neon instruction to be emitted. I don't see this as a worrying matter though, because I suspect that toolchains that have -mfpu=neon will have -mfloat-abi=hard as well and target cpus that have hw floating point capabilities, where such float instructions would cause no problem. The issue is not one of hardware availability. Using the VFP/NEON unit at all requires additional support beyond simply using the instructions. Firstly, the coprocessor must be enabled, which although a trivial operation does add complexity and maintenance burden. Secondly, any code run in an interrupt context must be somehow arranged to be free of VFP/NEON code, or the VFP context must be saved and restored around interrupt handlers. The latter is a bad idea since it significantly slows interrupt handling. This leaves us with the former option, and if some code must be VFP-free, that requirement might as well be extended to all code with no additional burden. The simplest way to make sure no VFP or NEON instructions are used is to pass -msoft-float to the compiler. Since linking to libgcc is an error in u-boot, ABI compatibility with it is of no concern. To summarise, I think using -msoft-float is good. Supporting floating-point in u-boot is more trouble than it's worth, and -msoft-float is an easy way to make sure the code is clean. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V3] at91sam9261ek: make operational again
Dear Remy Bohmer, In message aanlktinwsi4nnxkhfcns19e7ybj78kqjylgqg9lba...@mail.gmail.com you wrote: I'd recommend setting this to the very beginning of SDRAM(0x2000), note that initial SP and GD would be put into SRAM further down. The SRAM is used by the LCD controller. So, we cannot use it for the SP and GD. Why not? LCD is most probably only initialized and used after relocation, while stack and GD are needed and used only before that... +#define CONFIG_SYS_SDRAM_SIZE 0x0400 /* 64 megs */ It is up to you, but (64 20) might look nicer. This is more a matter of taste I think. I will see what I do with it. It's not only a matter of taste, but also a matter of readability. If I see 0x0400 I cannot really tell immediately if this is a bit mask or anything else, and even if I know from the context that it's a size, I cannot immediately say how much it is. On the other hand, a notation like 64 * 1024 * 1024 or (shorter) 64 20 makes it immediately clear that 1) it's some number, probably a size, and 2) that it's 64 MiB. In the interest of maitainability please chose a more readable way to specify such numbers. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Es ist nicht genug zu wissen, man muß auch anwenden; es ist nicht ge- nug zu wollen, man muß auch tun. -- Goethe, Maximen und Reflexionen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=, In message yw1x7hcw5f6w@unicorn.mansr.com you wrote: So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) I guess it's there to make sure no floating-point instructions make it into u-boot, even though floats are not used in the code. Perhaps someone was paranoid. No. There are pretty good reasons to use -msoft-float. On some systems certain versions of GCC will optimize certain operations (usually corresponding to 8 byte memory copy things) by using FP registers. -msoft-float prevents that. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Life would be so much easier if we could just look at the source code. -- Dave Olson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear Albert ARIBAUD, In message 4d5fcaca.1060...@free.fr you wrote: And since some option must be chosen, I prefer that U-Boot make the explicit decision, and choose soft float for the reasons I already exposed. I explained this several times before. There are good reasons to have -msoft-float. If the tool chain has problems by not providing soft-float libgcc routines, the user can always use the U-Boot provided library functions. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Teenagers are people who express a burning desire to be different by dressing exactly alike. There are some strings. They're just not attached. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear Alexander Holler, In message 4d5fce64.8030...@ahsoftware.de you wrote: I don't see any reason to explicitly set an option for something which isn't used, but I know of many reasons to avoid such. ;) Read my previous messages, and/or the archives. There _are_ good reasons that -msoft-float is used. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de NOTE: The Most Fundamental Particles in This Product Are Held Together by a Gluing Force About Which Little is Currently Known and Whose Adhesive Power Can Therefore Not Be Permanently Guaranteed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=, In message yw1xy65c3xfi@unicorn.mansr.com you wrote: There is one further complication here. If the compiler was built with -mfpu=3Dneon as default, it might emit neon instructions for pure integer code. For the purpose of this discussion, such instructions should still be regarded as floating-point since they are tied to the VFP. Such code generation is disabled by -msoft-float. Right. May we now just agree that -msoft-float is a matter of fact and mandatory in U-Boot. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say I told you so when it doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear Alexander Holler, In message 4d5fe485.5030...@ahsoftware.de you wrote: Hmm, but as we've seen, that doesn't work for all platforms because you can't mix softfloat and hardfloat. So using softfloat breaks building on (default-) hardfloat platforms if some poor soul puts floating point code in (which requires hardfloat-libraries too). A Perfect Tool Chain (TM) should provide all the needed libgcc support. If it fails to do that, then U-Boot provides all the needed library functions, you just have to use them. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The day-to-day travails of the IBM programmer are so amusing to most of us who are fortunate enough never to have been one - like watching Charlie Chaplin trying to cook a shoe. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reading from NAND
Dear D Kesselring,
In message AANLkTik=nRPJpeYTiW2Xg3+qtZ9hZ-pei6LO=cbrw...@mail.gmail.com you
wrote:
After some experimenting the only issue that I have now is trying to
do an itest on a non-aligned byte. I get an alignment exception if I
test a non-word aligned bype. Is there a way to do a bitwise AND so
that I can read a word and mask out the byte that I am interested in?
Also does the shell support adding values like itest *(${base} +
${offset}) == 0x01?
Why do you want to read a word when you are only interested in a
single byte? This sounds somewhat stupid.
Is there any reason for not using itest.b directly?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The universe does not have laws - it has habits, and habits can be
broken.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] reasons for armv5 as default
Dear Alexander Holler, In message 4d5fe8f0.1020...@ahsoftware.de you wrote: Btw, while we are there, is there any reason, besides being carefull, why u-boot for arm is compiled with -march=armv5(te) by default? Because that's the lowest ARM instruction set version supported widely across available tool chains. I'm just curious if there are some reasons for not using march=amrv7a for armv7 platforms and don't want to start a discussion about removing that default. Well, a major reason for not doing this is that amrv7a is a typo :-P Other reasons are for example explained in doc/README.omap3 or doc/README.s5pc1xx Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Command, n.: Statement presented by a human and accepted by a computer in such a manner as to make the human feel as if he is in control. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ATMEL REWORK][V2] update arm/at91rm9200 work with rework rework110202
Dear Jens Scharsig, In message 4d5fee3d.2000...@scharsoft.de you wrote: I don't know, why my checkpatch version does not report this. Try and update against curent Linux kernel version. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In an organization, each person rises to the level of his own incom- petency - The Peter Principle ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] USB: Add USB RNDIS gadget protocol
Hi, 2011/2/11 Vitaly Kuzmichev vkuzmic...@mvista.com: Port USB gadget RNDIS protocol support from linux-2.6.26 (.27 gadget stack actually has composite drivers). Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com --- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/ether.c | 640 +++-- drivers/usb/gadget/ndis.h | 217 +++ drivers/usb/gadget/rndis.c | 1312 +++ drivers/usb/gadget/rndis.h | 252 + include/linux/usb/cdc.h | 6 +- 6 files changed, 2367 insertions(+), 61 deletions(-) create mode 100644 drivers/usb/gadget/ndis.h create mode 100644 drivers/usb/gadget/rndis.c create mode 100644 drivers/usb/gadget/rndis.h Applied to u-boot-usb. Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] USB-RNDIS: Send RNDIS state on disconnecting
Hi, 2011/2/11 Vitaly Kuzmichev vkuzmic...@mvista.com: Add waiting for receiving Ethernet gadget state on the Windows host side before dropping pullup, but keep it for debug. Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com --- drivers/usb/gadget/ether.c | 23 +++ drivers/usb/gadget/rndis.c | 5 + drivers/usb/gadget/rndis.h | 8 3 files changed, 36 insertions(+), 0 deletions(-) Applied to u-boot-usb. Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear Raghuveer Murthy, In message 1298042212-12260-1-git-send-email-raghuveer.mur...@ti.com you wrote: U-boot built for MeeGo on PandaBoard, with compiler option -mfloat-abi=hard, caused a build break. Please refer to the bug id: http://bugs.meego.com/show_bug.cgi?id=13140 Removing the -msoft-float options in the config.mk files, allowed it to be built for both armv7hl and armv7el compilers on MeeGo Please refer to the below link for more details: http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal Signed-off-by: Raghuveer Murthy raghuveer.mur...@ti.com --- arch/arm/cpu/armv7/config.mk |2 +- arch/arm/cpu/armv7/omap-common/config.mk |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) After we had just another round of these discussions I thing we have again found an agreement that there are good reasons for using -msoft-float. I hereby reject your patch. If you have problems with your tool chain, please feel free to use the U-Boot provided libgcc functions instead (by providing USE_PRIVATE_LIBGCC=yes on the command line) or even your private libgcc code (by providing USE_PRIVATE_LIBGCC=directory_with_your_lib on the command line). Or fix your tool chain so it provides a soft-float version of the needed library routines, too. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Speculation is always more interesting than facts. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V3] at91sam9261ek: make operational again
Hi, The SRAM is used by the LCD controller. So, we cannot use it for the SP and GD. Why not? LCD is most probably only initialized and used after relocation, while stack and GD are needed and used only before that... I think you are right. I did not thought about that... +#define CONFIG_SYS_SDRAM_SIZE 0x0400 /* 64 megs */ It is up to you, but (64 20) might look nicer. This is more a matter of taste I think. I will see what I do with it. It's not only a matter of taste, but also a matter of readability. 100% agreed. If I see 0x0400 I cannot really tell immediately if this is a bit mask or anything else, and even if I know from the context that it's a size, I cannot immediately say how much it is. On the other hand, a notation like 64 * 1024 * 1024 or (shorter) 64 20 makes it immediately clear that 1) it's some number, probably a size, and 2) that it's 64 MiB. In the interest of maitainability please chose a more readable way to specify such numbers. If it should be 64 * 1024 * 1024, I completely agree with you. But, IMHO 64 20 is even less clear, this suggest a bitmask, while it is a size. I will change it to the longer style, since it only differs 8 characters... Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reading from NAND
Dear D Kesselring, please keep the mailing list on Cc:, and don;t top post / full quote. You may want to read http://www.netmeister.org/news/learn2quote.html In message AANLkTik3hq8tUc5-Uh23G=f0of2q8qnzj2fo+jcr3...@mail.gmail.com you wrote: This is for an embedded system and I am trying to read a nand location to determine which Linux image to boot. How can U-Boot run scripts automatically? Put some run your_macro_name in bootcmd and/or preboot. Read the manual about how to use these environment variables. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. - Howard Aiken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reading from NAND
Dear D Kesselring, please keep the mailing list on Cc:, and don't top post / full quote. In message AANLkTimn1deSepOQOUTVbD=c5-njULYNc=tqaw9tk...@mail.gmail.com you wrote: I think understand what you mean now. I can add a script to bootcmd before kicking off Linux. I did not know that the Uboot scripts would support if-else statements. Is there a simple way within a script to ask for user input for testing things? You can for example use the askenv command. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Cogito cogito ergo cogito sum - I think that I think, therefore I think that I am. - Ambrose Bierce, The Devil's Dictionary ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-usb
The following changes since commit efb063390d2d1e712c2c8110911616244d562c4b: add checking the CONFIG_ENV_IS_IN_SPI_FLASH in Enbedded env (2011-02-15 22:09:50 +0100) are available in the git repository at: git://git.denx.de/u-boot-usb.git master Remy Bohmer (2): Fix build warnings in cmd_flash.c Fix compile warning in net/eth.c Simon Glass (3): Fix EHCI usb submit timeout and unify with OHCI Add USB host ethernet adapter support Add support for ASIX AX88772 USB 2.0 10/100Mbit Ethernet Adaptor Vitaly Kuzmichev (5): USB-CDC: handle interrupt after dropped pullup USB-CDC: Port struct net_device_stats USB-CDC: Move struct declaration before its use USB: Add USB RNDIS gadget protocol USB-RNDIS: Send RNDIS state on disconnecting Makefile|1 + common/cmd_flash.c |8 +- common/cmd_usb.c| 12 +- common/usb.c|6 +- doc/README.usb |4 +- drivers/usb/eth/Makefile| 48 ++ drivers/usb/eth/asix.c | 635 + drivers/usb/eth/usb_ether.c | 150 + drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/ether.c | 775 ++--- drivers/usb/gadget/ndis.h | 217 +++ drivers/usb/gadget/rndis.c | 1317 +++ drivers/usb/gadget/rndis.h | 260 + drivers/usb/host/ehci-hcd.c | 10 +- drivers/usb/host/ohci-hcd.c |7 +- include/linux/netdevice.h | 65 +++ include/linux/usb/cdc.h |6 +- include/usb.h | 15 +- include/usb_ether.h | 68 +++ net/eth.c | 43 +- 20 files changed, 3519 insertions(+), 129 deletions(-) create mode 100644 drivers/usb/eth/Makefile create mode 100644 drivers/usb/eth/asix.c create mode 100644 drivers/usb/eth/usb_ether.c create mode 100644 drivers/usb/gadget/ndis.h create mode 100644 drivers/usb/gadget/rndis.c create mode 100644 drivers/usb/gadget/rndis.h create mode 100644 include/linux/netdevice.h create mode 100644 include/usb_ether.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-usb
Dear Remy Bohmer, In message AANLkTi=WCosZc8XPQxibuoWbcV7mWNDQ4oWr=bcql...@mail.gmail.com you wrote: The following changes since commit efb063390d2d1e712c2c8110911616244d562c4b: add checking the CONFIG_ENV_IS_IN_SPI_FLASH in Enbedded env (2011-02-15 22:09:50 +0100) are available in the git repository at: git://git.denx.de/u-boot-usb.git master Remy Bohmer (2): Fix build warnings in cmd_flash.c Fix compile warning in net/eth.c These are in no way USB related. You are not supposed to pull such stuff into your repository. Simon Glass (3): Fix EHCI usb submit timeout and unify with OHCI Add USB host ethernet adapter support Add support for ASIX AX88772 USB 2.0 10/100Mbit Ethernet Adaptor Vitaly Kuzmichev (5): USB-CDC: handle interrupt after dropped pullup USB-CDC: Port struct net_device_stats USB-CDC: Move struct declaration before its use USB: Add USB RNDIS gadget protocol USB-RNDIS: Send RNDIS state on disconnecting Makefile|1 + common/cmd_flash.c |8 +- common/cmd_usb.c| 12 +- common/usb.c|6 +- doc/README.usb |4 +- drivers/usb/eth/Makefile| 48 ++ drivers/usb/eth/asix.c | 635 + drivers/usb/eth/usb_ether.c | 150 + drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/ether.c | 775 ++--- drivers/usb/gadget/ndis.h | 217 +++ drivers/usb/gadget/rndis.c | 1317 +++ drivers/usb/gadget/rndis.h | 260 + drivers/usb/host/ehci-hcd.c | 10 +- drivers/usb/host/ohci-hcd.c |7 +- include/linux/netdevice.h | 65 +++ include/linux/usb/cdc.h |6 +- include/usb.h | 15 +- include/usb_ether.h | 68 +++ net/eth.c | 43 +- 20 files changed, 3519 insertions(+), 129 deletions(-) create mode 100644 drivers/usb/eth/Makefile create mode 100644 drivers/usb/eth/asix.c create mode 100644 drivers/usb/eth/usb_ether.c create mode 100644 drivers/usb/gadget/ndis.h create mode 100644 drivers/usb/gadget/rndis.c create mode 100644 drivers/usb/gadget/rndis.h create mode 100644 include/linux/netdevice.h create mode 100644 include/usb_ether.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are 2 Kinds of planes: Fighters, and targets. There are 2 Kinds of boats: Submarines, and targets. There are 2 Kinds of 4x4's: Jeeps and SOB's (Some other brand) There are 2 Kinds of OS's: Unix, and brain-farts. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to use board specific #defines during building of linker script
On Sunday, February 20, 2011, Mike Frysinger vap...@gentoo.org wrote: On Thursday, February 17, 2011 16:52:14 Graeme Russ wrote: But why not just include config.h when building u-boot.lds? why not include it yourself ? #include config.h Um, maybe a stupid question, but where (without touching common code)? ive been doing this for years in the Blackfin arch (long before preprocessing the linker script was considered fashionable). So it sounds like including config.h on les builds does not cause any issues. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to use board specific #defines during building of linker script
On Saturday, February 19, 2011 17:00:30 Graeme Russ wrote: On Sunday, February 20, 2011, Mike Frysinger vap...@gentoo.org wrote: On Thursday, February 17, 2011 16:52:14 Graeme Russ wrote: But why not just include config.h when building u-boot.lds? why not include it yourself ? #include config.h Um, maybe a stupid question, but where (without touching common code)? in the linker script -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to use board specific #defines during building of linker script
On Sunday, February 20, 2011, Mike Frysinger vap...@gentoo.org wrote: On Saturday, February 19, 2011 17:00:30 Graeme Russ wrote: On Sunday, February 20, 2011, Mike Frysinger vap...@gentoo.org wrote: On Thursday, February 17, 2011 16:52:14 Graeme Russ wrote: But why not just include config.h when building u-boot.lds? why not include it yourself ? #include config.h Um, maybe a stupid question, but where (without touching common code)? in the linker script Yeah, I thought of that 5 minutes after hitting send :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] reasons for armv5 as default
Hello, Am 19.02.2011 18:48, schrieb Albert ARIBAUD: You're missing the fact that floating point code is a no-no in U-Boot. We're not talking about the best option to support floating-point code in U-Boot, but the best option to catch the use of floating point. Please don't turn the words in my mouth. Anyway, I now know why -msoft-float is used. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: Add comments why -msoft-float is used.
Without -msoft-float the compiler would be allowed to use certain floating-point instructions (VFP/NEON) e.g. for optimizations, which would require additional code, for example to save contexts for interrupts. Add a comment which describes this in short words. Signed-off-by: Alexander Holler hol...@ahsoftware.de --- arch/arm/cpu/arm1136/config.mk |2 ++ arch/arm/cpu/arm1176/config.mk |2 ++ arch/arm/cpu/arm1176/s3c64xx/config.mk |2 ++ arch/arm/cpu/arm720t/config.mk |1 + arch/arm/cpu/arm920t/config.mk |1 + arch/arm/cpu/arm925t/config.mk |1 + arch/arm/cpu/arm926ejs/config.mk |1 + arch/arm/cpu/arm926ejs/davinci/config.mk |1 + arch/arm/cpu/arm946es/config.mk |1 + arch/arm/cpu/arm_intcm/config.mk |1 + arch/arm/cpu/armv7/config.mk |2 ++ arch/arm/cpu/armv7/omap-common/config.mk |2 ++ arch/arm/cpu/ixp/config.mk |1 + arch/arm/cpu/lh7a40x/config.mk |1 + arch/arm/cpu/pxa/config.mk |1 + arch/arm/cpu/s3c44b0/config.mk |1 + arch/arm/cpu/sa1100/config.mk|1 + 17 files changed, 22 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm1136/config.mk b/arch/arm/cpu/arm1136/config.mk index 3e68535..e2c32c0 100644 --- a/arch/arm/cpu/arm1136/config.mk +++ b/arch/arm/cpu/arm1136/config.mk @@ -20,6 +20,8 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # + +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float # Make ARMv5 to allow more compilers to work, even though its v6. diff --git a/arch/arm/cpu/arm1176/config.mk b/arch/arm/cpu/arm1176/config.mk index 14346cf..a9a36b4 100644 --- a/arch/arm/cpu/arm1176/config.mk +++ b/arch/arm/cpu/arm1176/config.mk @@ -20,6 +20,8 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # + +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float # Make ARMv5 to allow more compilers to work, even though its v6. diff --git a/arch/arm/cpu/arm1176/s3c64xx/config.mk b/arch/arm/cpu/arm1176/s3c64xx/config.mk index 14346cf..a9a36b4 100644 --- a/arch/arm/cpu/arm1176/s3c64xx/config.mk +++ b/arch/arm/cpu/arm1176/s3c64xx/config.mk @@ -20,6 +20,8 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # + +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float # Make ARMv5 to allow more compilers to work, even though its v6. diff --git a/arch/arm/cpu/arm720t/config.mk b/arch/arm/cpu/arm720t/config.mk index 3844c62..1d59f60 100644 --- a/arch/arm/cpu/arm720t/config.mk +++ b/arch/arm/cpu/arm720t/config.mk @@ -22,6 +22,7 @@ # MA 02111-1307 USA # +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float PLATFORM_CPPFLAGS += -march=armv4 -mtune=arm7tdmi diff --git a/arch/arm/cpu/arm920t/config.mk b/arch/arm/cpu/arm920t/config.mk index 8f6c1a3..b595088 100644 --- a/arch/arm/cpu/arm920t/config.mk +++ b/arch/arm/cpu/arm920t/config.mk @@ -21,6 +21,7 @@ # MA 02111-1307 USA # +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float PLATFORM_CPPFLAGS += -march=armv4 diff --git a/arch/arm/cpu/arm925t/config.mk b/arch/arm/cpu/arm925t/config.mk index 8f6c1a3..b595088 100644 --- a/arch/arm/cpu/arm925t/config.mk +++ b/arch/arm/cpu/arm925t/config.mk @@ -21,6 +21,7 @@ # MA 02111-1307 USA # +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float PLATFORM_CPPFLAGS += -march=armv4 diff --git a/arch/arm/cpu/arm926ejs/config.mk b/arch/arm/cpu/arm926ejs/config.mk index f8ef90f..fb83862 100644 --- a/arch/arm/cpu/arm926ejs/config.mk +++ b/arch/arm/cpu/arm926ejs/config.mk @@ -21,6 +21,7 @@ # MA 02111-1307 USA # +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float PLATFORM_CPPFLAGS += -march=armv5te diff --git a/arch/arm/cpu/arm926ejs/davinci/config.mk b/arch/arm/cpu/arm926ejs/davinci/config.mk index 565adda..081c13d 100644 --- a/arch/arm/cpu/arm926ejs/davinci/config.mk +++ b/arch/arm/cpu/arm926ejs/davinci/config.mk @@ -21,6 +21,7 @@ # MA 02111-1307 USA # +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float PLATFORM_CPPFLAGS += -march=armv5te diff --git a/arch/arm/cpu/arm946es/config.mk b/arch/arm/cpu/arm946es/config.mk index e783f69..f7db925 100644 --- a/arch/arm/cpu/arm946es/config.mk +++ b/arch/arm/cpu/arm946es/config.mk @@ -21,6 +21,7 @@ # MA
