[U-Boot] [RESEND PATCH v2 6/6] sf: Fix code cleanups
- CHECK: Alignment should match open parenthesis
- trailing whitespace
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/atmel.c| 10 +-
drivers/mtd/spi/gigadevice.c | 2 +-
drivers/mtd/spi/ramtron.c | 2 +-
drivers/mtd/spi/spansion.c | 2 +-
drivers/mtd/spi/spi_spl_load.c | 2 +-
drivers/mtd/spi/sst.c | 6 +++---
drivers/mtd/spi/stmicro.c | 5 +++--
drivers/mtd/spi/winbond.c | 2 +-
8 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/mtd/spi/atmel.c b/drivers/mtd/spi/atmel.c
index 6a92c4b..f34df43 100644
--- a/drivers/mtd/spi/atmel.c
+++ b/drivers/mtd/spi/atmel.c
@@ -252,7 +252,7 @@ static int dataflash_write_p2(struct spi_flash *flash,
}
debug(SF: AT45: Successfully programmed %zu bytes @ 0x%x\n,
- len, offset);
+ len, offset);
ret = 0;
out:
@@ -325,7 +325,7 @@ static int dataflash_write_at45(struct spi_flash *flash,
}
debug(SF: AT45: Successfully programmed %zu bytes @ 0x%x\n,
- len, offset);
+ len, offset);
ret = 0;
out:
@@ -387,7 +387,7 @@ static int dataflash_erase_p2(struct spi_flash *flash, u32
offset, size_t len)
}
debug(SF: AT45: Successfully erased %zu bytes @ 0x%x\n,
- len, offset);
+ len, offset);
ret = 0;
out:
@@ -450,7 +450,7 @@ static int dataflash_erase_at45(struct spi_flash *flash,
u32 offset, size_t len)
}
debug(SF: AT45: Successfully erased %zu bytes @ 0x%x\n,
- len, offset);
+ len, offset);
ret = 0;
out:
@@ -476,7 +476,7 @@ struct spi_flash *spi_flash_probe_atmel(struct spi_slave
*spi, u8 *idcode)
if (i == ARRAY_SIZE(atmel_spi_flash_table)) {
debug(SF: Unsupported DataFlash ID %02x\n,
- idcode[1]);
+ idcode[1]);
return NULL;
}
diff --git a/drivers/mtd/spi/gigadevice.c b/drivers/mtd/spi/gigadevice.c
index 950c777..b42581a 100644
--- a/drivers/mtd/spi/gigadevice.c
+++ b/drivers/mtd/spi/gigadevice.c
@@ -45,7 +45,7 @@ struct spi_flash *spi_flash_probe_gigadevice(struct spi_slave
*spi, u8 *idcode)
if (i == ARRAY_SIZE(gigadevice_spi_flash_table)) {
debug(SF: Unsupported Gigadevice ID %02x%02x\n,
- idcode[1], idcode[2]);
+ idcode[1], idcode[2]);
return NULL;
}
diff --git a/drivers/mtd/spi/ramtron.c b/drivers/mtd/spi/ramtron.c
index 27e6411..38f9d69 100644
--- a/drivers/mtd/spi/ramtron.c
+++ b/drivers/mtd/spi/ramtron.c
@@ -266,7 +266,7 @@ struct spi_flash *spi_fram_probe_ramtron(struct spi_slave
*spi, u8 *idcode)
/* arriving here means no method has found a device we can handle */
debug(SF/ramtron: unsupported device id0=%02x id1=%02x id2=%02x\n,
- idcode[0], idcode[1], idcode[2]);
+ idcode[0], idcode[1], idcode[2]);
return NULL;
found:
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index b9a36c2..fa7ac8c 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -6,7 +6,7 @@
* TsiChung Liew (tsi-chung.l...@freescale.com),
* and Jason McMullan (mcmul...@netapp.com)
*
- * SPDX-License-Identifier:GPL-2.0+
+ * SPDX-License-Identifier:GPL-2.0+
*/
#include common.h
diff --git a/drivers/mtd/spi/spi_spl_load.c b/drivers/mtd/spi/spi_spl_load.c
index 7c799ca..2935530 100644
--- a/drivers/mtd/spi/spi_spl_load.c
+++ b/drivers/mtd/spi/spi_spl_load.c
@@ -39,7 +39,7 @@ void spl_spi_load_image(void)
/* Load u-boot, mkimage header is 64 bytes. */
spi_flash_read(flash, CONFIG_SYS_SPI_U_BOOT_OFFS, 0x40,
- (void *) header);
+ (void *)header);
spl_parse_image_header(header);
spi_flash_read(flash, CONFIG_SYS_SPI_U_BOOT_OFFS,
spl_image.size, (void *)spl_image.load_addr);
diff --git a/drivers/mtd/spi/sst.c b/drivers/mtd/spi/sst.c
index 6292289..c9dec3c52 100644
--- a/drivers/mtd/spi/sst.c
+++ b/drivers/mtd/spi/sst.c
@@ -113,7 +113,7 @@ sst_byte_write(struct spi_flash *flash, u32 offset, const
void *buf)
};
debug(BP[%02x]: 0x%p = cmd = { 0x%02x 0x%06x }\n,
- spi_w8r8(flash-spi, CMD_READ_STATUS), buf, cmd[0], offset);
+ spi_w8r8(flash-spi, CMD_READ_STATUS), buf, cmd[0], offset);
ret = spi_flash_cmd_write_enable(flash);
if (ret)
@@ -160,8 +160,8 @@ sst_write_wp(struct spi_flash *flash, u32 offset, size_t
len, const void *buf)
for (; actual len - 1; actual += 2) {
debug(WP[%02x]: 0x%p = cmd = { 0x%02x 0x%06x }\n,
-spi_w8r8(flash-spi, CMD_READ_STATUS), buf + actual,
-cmd[0], offset);
+
Re: [U-Boot] Implement AUART for i.MX28
Hi Sorry for not responding, work and vacation came in the way. No further work has been done, ill see if i can do some next week. Kind regards Andreas 3 aug 2013 kl. 20:35 skrev Marek Vasut ma...@denx.de: Hi Andreas, I have tried to implement an AUART driver for i.MX28. However for it to work I must print 1 character to the debug UART via the serial_pl01x driver. If I do this the AUART will start working. If I don't nothing will be printed to the AUART. Anybody can see any obvious errors? Signed-off-by: Andreas Wass andreas.w...@dalelven.com I have to wonder, is the AUART no standard UART IP ? Probably not as Linux also has a separate driver for this ... Lots of rambling follows below, but please dont be put off by it. Make sure to CC me and Fabio on the next submission. I can help you debugging the driver if you clean it up a bit. Bump, is there any progress here? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Implement AUART for i.MX28
Hello Andreas, Hi Sorry for not responding, work and vacation came in the way. No further work has been done, ill see if i can do some next week. OK Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unified u-boot feature set for simpler distro support
Dear Dennis Gilmore, In message 20130803021104.1feca...@adria.ausil.us you wrote: I wanted to start a discussion on defining a unified feature set that makes it simpler for the different distros to support ARM systems using u-boot. I have based a lot of my thoughts on how calxeda ship their When talking about simplifying and unifying things, you should not start with the mistake of an architecture specific view. ARM may be what you are interested in, and where most of the current development is happening, but it is not the only architecture around. Also, it may make sense to start with leaning back a bit and looking how other architectures solved some of the issues ARM is having. My feeling is that some of them are actually home-made. right or wrong we want things to be simple for the user and to largely look like a linux system on x86 would. The user and distro should never need to worry about memory locations Actually it is a horror thought to me that U-Boot could degrade into such a horrible envrionment as the boot loaders (BIOS, UEFI etc.) provide, both to the developer and to the end user. No, this is definitely NOT where we waht to head for. so this would mean similar partitioning. i.e. /boot on ext4 root and swap on lvm or as raw partitions. people should be able to have just / on ext4 also. Down the road xfs /boot support would be a nice to have. This may be interesting for you, but faci it: the majority of boards are not using ext4 based root file systems, nor xfs. Most of them are strictly embedded devices, and the use of JFFS2 (yes, still!) and UBI/UBIFS on NOR and NAND flash is far more common. pxe boot suport, two reasons, one is to be able to easily network boot the distro installer, the other is to use sysboot support post install with a extlinux.conf file to specify the kernel, initrd and bootargs PXE may be interesting for a very small percentage of applications, but it is nothing to unify on. Existing DHCP / TFTP / NFS support is much more commonly used. bootz and raw initrd support. not having to wrap kernels and initrds really is a must. raw initrd support means that its much simpler for a Actually this is strictly an ARM issue. No other architecture has such problems. U-Boot images (both the old, legacy uImage format, and much more so the FIT imagesformat) have a large number of advantages, especially for software management on embedded systems. Also, a pretty common requirement in U-Boot land is boot time optimization. The common approach of standard distros with a multi-stage intialization sequence including booting from an intial ramdisk before mounting the real root file system is usually prohibitive in such szenarios. user to rebuild an initramfs if needed and bootz means we do not need to worry about making sure that we specify the correct addresses to load the kernel to when calling mkimage. Again, this is a problem home-made by ARM Linux. I am not ware of any such issues with other architectures. when it comes to memory addressing a distro and user shouldn't need to know anything. Ideally u-boot will auto allocate addresses based on the size of loaded objects. starting with a base address internal to u-boot you load a kernel, when loading an initramfs u-boot automatically calculates an address that ensures it does not overlap with the kernel. same for a fdt if loaded. I say auto calculated because what we think today will be enough room may not be tomorrow, dynamically calculating gives the flexibility for whatever may come. This is easy to say, but difficult to impossible to implement in the general case. The problem of dealing with compressed images where you usually don't know in advance how big they will become when uncompressed) has already been mentioned. The property especially of the ARM Linux kernel (in default setup) to copy itself around if it deems fit and some other such issues make things really complicated. When you talk of unifying, this must be done on both sides - the boot loader cannot solve or fix up all the issues caused elsewhere. output and input should happen on all possible devices and not just the serial console. If a user has a trimslice with only a HDMI monitor and usb keyboard they should be able to see the menu listing their possible kernels and be able to choose which one they want to boot. Such a requirement can never be fulfilled. For example, there are many embedded systems which have all kind of devices attached which would go haywire if you start sending console output to them. Fedora Boot Options. 1:Fedora (3.9.9-302.fc19.armv7hl) 19 (Schrödinger’s Cat) 2:Fedora (3.9.4-301.fc19.armv7hl) 19 (Schrödinger’s Cat) Enter choice: is the output on boot, the user can then enter 1 or 2 to select a kernel to boot. if nothing is selected the first option is booted after the timeout expires. You always assume that there is a user, who provides manual input, and such.
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
Dear Stefano, In message 51fb786e.4010...@denx.de you wrote: Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an environment image from a simple ASCII text. The resulting image could be concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we could have for all boards a way to load it. Only a first idea, but as we recognize the issue, any idea to solve it ? There is a ton of options, all way better than hardcoding any such settings into the common default environment - env import allows to easily import variable settings in a number of formats (including plain text), so you can just dedicate some storage speace, either on a raw device (like an address / offset range in NOR / NAND flash, or some sectors on a block device, or a file in a file system, or whatever. We never should extend the default environment into such a pile of stuff. 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 I am not now, nor have I ever been, a member of the demigodic party. -- Dennis Ritchie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
Dear Dennis, In message 20130801120603.1683f...@adria.ausil.us you wrote: ultimately I want to have a standard way to boot any system that just works and does not need the installer to know or care what the target system is. using boot.scr and uEnv.txt does not work for my goals. But your requirement is just one out of a number of such requirements, and I see no indication that an one size fits all approach would be possible. ultimately for Fedora we do not want to use uEnv.txt or boot.scr at all we want to use a extlinux.conf file and sysboot provided by cmd_pxe the rest is to provide flexibility and options to users to choose different ways to boot. the above is not at all suitable. Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: I'm right, you all are wrong. The thing is, that the overwhelming majority of systems are not running a standard distro like Fedora, and don't have any such features as boot extlinux.conf files or sysboot or whatever -they don;t have it, and they cannot afford it because they have totally different requirements to meet. Please try and keep this in mind. Yourrequiremetns are but a special case here - one which we will try to support in the best possible way, of course, but it's just one out of many. 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 Include the success of others in your dreams for your own success. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: fix conditional controlling call to fixup_silent_linux
Hi Paul, On Sun, Aug 4, 2013 at 1:59 PM, Paul B. Henson hen...@acm.org wrote: Looks like this was broken in commit 35fc84fa1ff51e15ecd3e464dac87eb105ffed30, the refactor changed the conditional test when the code was moved. This looks right. Acked-by: Simon Glass s...@chromium.org But which board does it actually break, please? On Sat, Aug 03, 2013 at 09:29:09PM -0700, Paul B. Henson wrote: This function is only defined if CONFIG_SILENT_CONSOLE is set and CONFIG_SILENT_U_BOOT_ONLY is not set, the call to it should be based on the same conditions. Signed-off-by: Paul B. Henson hen...@acm.org --- common/cmd_bootm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 046e22f..691d16b 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -636,7 +636,7 @@ static int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, goto err; else if (ret == BOOTM_ERR_OVERLAP) ret = 0; -#ifdef CONFIG_SILENT_CONSOLE +#if defined(CONFIG_SILENT_CONSOLE) !defined(CONFIG_SILENT_U_BOOT_ONLY) if (images-os.os == IH_OS_LINUX) fixup_silent_linux(); #endif -- 1.7.8.6 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
On Fri, Aug 02, 2013 at 11:14:22AM +0200, Stefano Babic wrote: Hi Rob, Dennis, On 01/08/2013 19:19, Rob Herring wrote: You both are missing the point. This patch doesn't address the problem, but does highlight it. I am aware of it - I have already pointed out that we get many patches that have increased the default environment to something hard to maintain. This patch makes it more obvious. The distros want to get out of having to know the u-boot environment details for every single board and need some level of standardization across platforms. The distros should only have to specify boot the kernel at path/name X on device Y. They should not need to know what address to load the kernel to, but only that $kernel_addr_r is already setup. Variables are the first step. The second step is standardizing the boot commands. I understand the point - but is the way to hard code together with u-boot the right way ? Do we have some other possibilities to do this ? Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an environment image from a simple ASCII text. The resulting image could be concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we could have for all boards a way to load it. Only a first idea, but as we recognize the issue, any idea to solve it ? Distros generally hate the thought of having the user update U-Boot. Part of why I asked Dennis to post his patches here is that we need to start the conversation at least, and come up with a way that boards are likely to ship out of the box in a way that can be worked from, consistently at least across different vendor same arch SoCs. This would require some opt-in per board, certainly. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 01/20] Add functions for use with i.mx6 otg udc
Dear Troy Kisky, In message 1375399657-25642-2-git-send-email-troy.ki...@boundarydevices.com you wrote: Add functions for use with mx6 soc void otg_enable(void); void reset_usb_phy1(void); Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- arch/arm/cpu/armv7/mx6/soc.c | 47 +++ arch/arm/include/asm/arch-mx6/crm_regs.h | 3 ++ arch/arm/include/asm/arch-mx6/imx-regs.h | 17 +++ arch/arm/include/asm/arch-mx6/sys_proto.h | 4 +++ 4 files changed, 71 insertions(+) This appears to be V3 of this patch series, but I cannot see any kind of change log? Please note that this is a mandatory requirement, see http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions Note this applies to the whole patch series. 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's no honorable way to kill, no gentle way to destroy. There is nothing good in war. Except its ending. -- Abraham Lincoln, The Savage Curtain, stardate 5906.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mac address warning
Dear Eric Nelson, In message 51faef05.1050...@boundarydevices.com you wrote: While testing Troy's usbnet patches, I was reminded of this mysterious warning issued when the environment has no mac address stored, but the device provides one: printf(\nWarning: %s using MAC address from net device\n, dev-name); Why is this a warning? It's the out-of-the box default for new boards who haven't saved a mac address to the persistent environment. It is a warnign because in U-Boot the ethaddr environment variable is considered the primary source of information here. If it is missing, U-Boot may try to use other sources for this information, but it will warn you that it is not doing the normal thing. 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 Everything should be made as simple as possible, but not simpler. - Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bootstopkey reason behind it
Dear paavaanan_...@dell.com, In message d5a6f3355f664c40afb65bb1277d8d450193b22...@maax7mcdc101.apac.dell.com you wrote: To stop autoboot we have 2 ifdef (CONFIG_AUTOBOOT_STOP_ [STR2 || STR1] ). Which is very easy and straightforward to implement. Halting a boot with single Keystroke is having its own advantages to the user. But, why multiple key support is ignored say like [ctrl + anykey ] combination. Especially, BIOS vendors prefer at least simultaneous pressing of 2 or more keys to halt the boot. Any specific reasons to avoid this. Other than simplicity is there any specific reason to stick on this. BIOSes and BIOS compatible extension cards (say, PCI controllers) are usually a major PITA when you are not working in an environment where you have a real keyboard attached. We're dealing with embedded devices here, and often we have only communication paths like a serial port (eventually even over a modem line), or netconsole. Have you ever tried to transmit some ALT + some_key control sequences over a serial port? I mean why simultaneous two key press support is avoided and implemented a secondary bootstopkey to halt the boot say like CONFIG_AUTOBOOT_STOP_STR2. This is done because usually we do not have a real keyboard. So anything that cannot be mapped into the standard ASCII character set cannot be used here. 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 Any fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: fix conditional controlling call to fixup_silent_linux
Looks like this was broken in commit 35fc84fa1ff51e15ecd3e464dac87eb105ffed30, the refactor changed the conditional test when the code was moved. On Sat, Aug 03, 2013 at 09:29:09PM -0700, Paul B. Henson wrote: This function is only defined if CONFIG_SILENT_CONSOLE is set and CONFIG_SILENT_U_BOOT_ONLY is not set, the call to it should be based on the same conditions. Signed-off-by: Paul B. Henson hen...@acm.org --- common/cmd_bootm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 046e22f..691d16b 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -636,7 +636,7 @@ static int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, goto err; else if (ret == BOOTM_ERR_OVERLAP) ret = 0; -#ifdef CONFIG_SILENT_CONSOLE +#if defined(CONFIG_SILENT_CONSOLE) !defined(CONFIG_SILENT_U_BOOT_ONLY) if (images-os.os == IH_OS_LINUX) fixup_silent_linux(); #endif -- 1.7.8.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mac address warning
Dear Stefano Babic, In message 51fbaf54.1090...@denx.de you wrote: Well, I have found it very useful in case I set explicitely the ethaddr variable, so I know where the MAC address comes from. Do you find it disturbing ? Maybe we could replace warning with info. No, warning is perfectly right here. We deviate from the normal initialization sequence, and the user should note that (and eventually take measures to resolve the problem). 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 Experience is that marvelous thing that enable you to recognize a mistake when you make it again. - Franklin P. Jones ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
On Sun, Aug 04, 2013 at 10:00:04PM +0200, Wolfgang Denk wrote: Dear Dennis, In message 20130801120603.1683f...@adria.ausil.us you wrote: ultimately I want to have a standard way to boot any system that just works and does not need the installer to know or care what the target system is. using boot.scr and uEnv.txt does not work for my goals. But your requirement is just one out of a number of such requirements, and I see no indication that an one size fits all approach would be possible. And today we have no ability to easily opt-in to any of the one size fits many approachs we have scattered about in config files today. ultimately for Fedora we do not want to use uEnv.txt or boot.scr at all we want to use a extlinux.conf file and sysboot provided by cmd_pxe the rest is to provide flexibility and options to users to choose different ways to boot. the above is not at all suitable. Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: I'm right, you all are wrong. Well, from their (the distro point of view) point of view, they don't want to have to come up with yet another set of tools (like they're having to do today, there's a rather large hunk of logic Fedora has for booting a handful of boards). I'd really love to see someone come up with a parser of extlinux.conf (http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/) for U-Boot. The thing is, that the overwhelming majority of systems are not running a standard distro like Fedora, and don't have any such features as boot extlinux.conf files or sysboot or whatever -they don;t have it, and they cannot afford it because they have totally different requirements to meet. Please try and keep this in mind. Yourrequiremetns are but a special case here - one which we will try to support in the best possible way, of course, but it's just one out of many. That a large number of maker folks are using ARM boards, that use Linux and U-Boot is a good thing. That it's quite a pain for each new board and user to get a familiar environment up, is a problem. And I would say the defaults in reference platforms should be pretty wide ranging. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
On Thu, Aug 01, 2013 at 12:19:13PM -0500, Rob Herring wrote:
On 08/01/2013 03:53 AM, Stefano Babic wrote:
Hi Dennis,
On 01/08/2013 01:27, Robert Nelson wrote:
[snip]
#define CONFIG_BOOTCOMMAND \
mmc dev ${mmcdev}; \
if mmc rescan; then \
echo SD/MMC found on device ${mmcdev}; \
if run loadbootenv; then \
run importbootenv; \
fi; \
if test -n $uenvcmd; then \
echo Running uenvcmd ...; \
run uenvcmd; \
fi; \
if run loadsomefailsafedefault; then \
run mmcboot; \
fi; \
fi;
#endif
That really works great on boards that don't have SD...
Don't lose the forest for the trees. A try and import stuff from
easy/prominent storage is true for most boards, be it SD or SATA or
NAND or ...
Right - the meaning of CONFIG_EXTRA_ENV_SETTINGS is to have a minimal
default environment, allowing the user to extend it to a full blown
adding whatever he wants. However, in the last times I see that the
meaning is moving to *the environment*. There is something wrong, also
because, as Robert says, each small change require to patch u-boot. But
then, why do you need the environment at all ?
And the setup is then suitable for a strict range of applications, but
not all.
You both are missing the point. This patch doesn't address the problem,
but does highlight it. The distros want to get out of having to know the
u-boot environment details for every single board and need some level of
standardization across platforms. The distros should only have to
specify boot the kernel at path/name X on device Y. They should not
need to know what address to load the kernel to, but only that
$kernel_addr_r is already setup. Variables are the first step. The
second step is standardizing the boot commands.
At the high level, right. But I think we need to know what the distros
need / what, and come up with an opt-in setup that works for both parts
(if a board follows the rules, it should easily work with whatever
distros provide feedback, if it doesn't then it might not, and boards
that care can opt-in and those that won't, can stay out).
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mac address warning
On 08/04/2013 01:24 PM, Wolfgang Denk wrote: Dear Stefano Babic, In message 51fbaf54.1090...@denx.de you wrote: Well, I have found it very useful in case I set explicitely the ethaddr variable, so I know where the MAC address comes from. Do you find it disturbing ? Maybe we could replace warning with info. No, warning is perfectly right here. We deviate from the normal initialization sequence, and the user should note that (and eventually take measures to resolve the problem). Thanks Wolfgang, Stefano and Tom straightened me out and I forwarded a patch to address the issue that mxc_fec.c wasn't properly setting a default ethaddr when an address is programmed in fuses. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
Dear Tom Rini, In message 20130804202746.GH5164@bill-the-cat you wrote: But your requirement is just one out of a number of such requirements, and I see no indication that an one size fits all approach would be possible. And today we have no ability to easily opt-in to any of the one size fits many approachs we have scattered about in config files today. I am not that pessimistic. The tools are all available and in place. env import (and other capabilities of the env command) allow to import any set of environment from any storage location U-Boot can handle. This allows to implement all kind of fancy features, like user profiles, reset to factory defaults, etc. etc. Of course it also allows to implement settings needed to support booting of a standard distribution. Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: I'm right, you all are wrong. Well, from their (the distro point of view) point of view, they don't want to have to come up with yet another set of tools (like they're having to do today, there's a rather large hunk of logic Fedora has for booting a handful of boards). I'd really love to see someone come up with a parser of extlinux.conf (http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/) for U-Boot. You mean, as an external tool, to translate extlinux.conf into a set of U-Boot commands? The thing is, that the overwhelming majority of systems are not running a standard distro like Fedora, and don't have any such features as boot extlinux.conf files or sysboot or whatever -they don;t have it, and they cannot afford it because they have totally different requirements to meet. Please try and keep this in mind. Yourrequiremetns are but a special case here - one which we will try to support in the best possible way, of course, but it's just one out of many. That a large number of maker folks are using ARM boards, that use Linux and U-Boot is a good thing. That it's quite a pain for each new board and user to get a familiar environment up, is a problem. And I would say the defaults in reference platforms should be pretty wide ranging. Define reference platform? Do you think, for example, systems in the class of TI's AM1808 or Freescale's i.MX28 are adequate targets to run Fedora? Does Fedora actually support any targets below ARMv7 ? 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 Der Irrtum wiederholt sich immerfort in der Tat. Deshalb muß man das Wahre unermüdlich in Worten wiederholen. - Goethe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/12] sf: probe: Update sector_size for W25* parts
Updated/Corrected the sector_size as per the datasheets.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash_probe.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index 1be55b3..3ffc94f 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -74,24 +74,24 @@ static const struct {
{N25Q1024A, 0x20bb21, 0x0,64 * 1024,2048},
/* WINBOND */
- {W25P80, 0xef2014, 0x0,65536,16},
- {W25P16, 0xef2015, 0x0,65536,32},
- {W25P32, 0xef2016, 0x0,65536,64},
- {W25X40, 0xef3013, 0x0,4096, 8},
- {W25X16, 0xef3015, 0x0,4096, 32},
- {W25X32, 0xef3016, 0x0,4096, 64},
- {W25X64, 0xef3017, 0x0,4096, 128},
- {W25Q80BL,0xef4014, 0x0,4096, 16},
- {W25Q16CL,0xef4015, 0x0,4096, 32},
- {W25Q32BV,0xef4016, 0x0,4096, 64},
- {W25Q64CV,0xef4017, 0x0,4096, 128},
- {W25Q128BV, 0xef4018, 0x0,4096, 256},
- {W25Q256, 0xef4019, 0x0,4096, 512},
- {W25Q80BW,0xef5014, 0x0,4096, 16},
- {W25Q16DW,0xef6015, 0x0,4096, 32},
- {W25Q32DW,0xef6016, 0x0,4096, 64},
- {W25Q64DW,0xef6017, 0x0,4096, 128},
- {W25Q128FW, 0xef6018, 0x0,4096, 256},
+ {W25P80, 0xef2014, 0x0,64 * 1024,16},
+ {W25P16, 0xef2015, 0x0,64 * 1024,32},
+ {W25P32, 0xef2016, 0x0,64 * 1024,64},
+ {W25X40, 0xef3013, 0x0,64 * 1024,8},
+ {W25X16, 0xef3015, 0x0,64 * 1024,32},
+ {W25X32, 0xef3016, 0x0,64 * 1024,64},
+ {W25X64, 0xef3017, 0x0,64 * 1024,128},
+ {W25Q80BL,0xef4014, 0x0,64 * 1024,16},
+ {W25Q16CL,0xef4015, 0x0,64 * 1024,32},
+ {W25Q32BV,0xef4016, 0x0,64 * 1024,64},
+ {W25Q64CV,0xef4017, 0x0,64 * 1024,128},
+ {W25Q128BV, 0xef4018, 0x0,64 * 1024,256},
+ {W25Q256, 0xef4019, 0x0,64 * 1024,512},
+ {W25Q80BW,0xef5014, 0x0,64 * 1024,16},
+ {W25Q16DW,0xef6015, 0x0,64 * 1024,32},
+ {W25Q32DW,0xef6016, 0x0,64 * 1024,64},
+ {W25Q64DW,0xef6017, 0x0,64 * 1024,128},
+ {W25Q128FW, 0xef6018, 0x0,64 * 1024,256},
/*
* Note:
* Below paired flash devices has similar spi_flash_ids attributes.
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/12] sf: probe: Update sector_size for S25FL* parts
Updated/Corrected the sector_size as per the datasheets.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash_probe.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index 054c166..f265e04 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -52,17 +52,17 @@ static const struct {
{EN25Q128B, 0x1c3018, 0x0,64 * 1024,256},
/* SPANSION */
- {S25FL008A, 0x010213, 0x0,256 * 256,16},
- {S25FL016A, 0x010214, 0x0,256 * 256,32},
- {S25FL032A, 0x010215, 0x0,256 * 256,64},
- {S25FL064A, 0x010216, 0x0,256 * 256,128},
- {S25FL128P_64K, 0x012018, 0x0301, 256 * 256,256},
+ {S25FL008A, 0x010213, 0x0,64 * 1024,16},
+ {S25FL016A, 0x010214, 0x0,64 * 1024,32},
+ {S25FL032A, 0x010215, 0x0,64 * 1024,64},
+ {S25FL064A, 0x010216, 0x0,64 * 1024,128},
{S25FL128P_256K, 0x012018, 0x0300, 256 * 1024, 64},
- {S25FL032P, 0x010215, 0x4d00, 256 * 256,64},
- {S25FL064P, 0x010216, 0x4d00, 256 * 256,128},
- {S25FL128S_64K, 0x012018, 0x4d01, 256 * 256,256},
- {S25FL256S_64K, 0x010219, 0x4d01, 256 * 256,512},
- {S25FL512S_64K, 0x010220, 0x4d01, 256 * 256,1024},
+ {S25FL128P_64K, 0x012018, 0x0301, 64 * 1024,256},
+ {S25FL032P, 0x010215, 0x4d00, 64 * 1024,64},
+ {S25FL064P, 0x010216, 0x4d00, 64 * 1024,128},
+ {S25FL128S_64K, 0x012018, 0x4d01, 64 * 1024,256},
+ {S25FL256S_64K, 0x010219, 0x4d01, 64 * 1024,512},
+ {S25FL512S_64K, 0x010220, 0x4d01, 64 * 1024,1024},
/* STMICRO */
{M25P10, 0x202011, 0x0,32 * 1024,4},
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/12] sf: Divide spi_flash into multiple parts
Divided the spi_flash framework into mutiple parts for
- spi_flash.c:
spi flash core file, interaction for spi/qspi driver to
spi_flash framework.
- spi_flash_ops.c
spi flash preffered operations, erase,write and read.
- spi_flash_probe.c
spi flash probing, easy to extend probing functionality.
This change will support to extend the functionality in a
proper manner.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/Makefile | 2 +-
drivers/mtd/spi/spi_flash.c | 569 +-
drivers/mtd/spi/spi_flash_ops.c | 314 +
drivers/mtd/spi/spi_flash_probe.c | 274 ++
4 files changed, 594 insertions(+), 565 deletions(-)
create mode 100644 drivers/mtd/spi/spi_flash_ops.c
create mode 100644 drivers/mtd/spi/spi_flash_probe.c
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index e537fcf..0304b12 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -13,7 +13,7 @@ ifdef CONFIG_SPL_BUILD
COBJS-$(CONFIG_SPL_SPI_LOAD) += spi_spl_load.o
endif
-COBJS-$(CONFIG_SPI_FLASH) += spi_flash.o
+COBJS-$(CONFIG_SPI_FLASH) += spi_flash_probe.o spi_flash_ops.o spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
COBJS-$(CONFIG_SPI_FLASH_EON) += eon.o
COBJS-$(CONFIG_SPI_FLASH_GIGADEVICE) += gigadevice.o
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 9814395..ddbdda0 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -8,23 +8,7 @@
*/
#include common.h
-#include fdtdec.h
-#include malloc.h
#include spi.h
-#include spi_flash.h
-#include watchdog.h
-
-#include spi_flash_internal.h
-
-DECLARE_GLOBAL_DATA_PTR;
-
-static void spi_flash_addr(u32 addr, u8 *cmd)
-{
- /* cmd[0] is actual command */
- cmd[1] = addr 16;
- cmd[2] = addr 8;
- cmd[3] = addr 0;
-}
static int spi_flash_read_write(struct spi_slave *spi,
const u8 *cmd, size_t cmd_len,
@@ -52,562 +36,19 @@ static int spi_flash_read_write(struct spi_slave *spi,
return ret;
}
-int spi_flash_cmd(struct spi_slave *spi, u8 cmd, void *response, size_t len)
-{
- return spi_flash_cmd_read(spi, cmd, 1, response, len);
-}
-
int spi_flash_cmd_read(struct spi_slave *spi, const u8 *cmd,
size_t cmd_len, void *data, size_t data_len)
{
return spi_flash_read_write(spi, cmd, cmd_len, NULL, data, data_len);
}
-int spi_flash_cmd_write(struct spi_slave *spi, const u8 *cmd, size_t cmd_len,
- const void *data, size_t data_len)
-{
- return spi_flash_read_write(spi, cmd, cmd_len, data, NULL, data_len);
-}
-
-int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
-{
- struct spi_slave *spi = flash-spi;
- unsigned long timebase;
- int ret;
- u8 status;
- u8 check_status = 0x0;
- u8 poll_bit = STATUS_WIP;
- u8 cmd = flash-poll_cmd;
-
- if (cmd == CMD_FLAG_STATUS) {
- poll_bit = STATUS_PEC;
- check_status = poll_bit;
- }
-
- ret = spi_xfer(spi, 8, cmd, NULL, SPI_XFER_BEGIN);
- if (ret) {
- debug(SF: fail to read %s status register\n,
- cmd == CMD_READ_STATUS ? read : flag);
- return ret;
- }
-
- timebase = get_timer(0);
- do {
- WATCHDOG_RESET();
-
- ret = spi_xfer(spi, 8, NULL, status, 0);
- if (ret)
- return -1;
-
- if ((status poll_bit) == check_status)
- break;
-
- } while (get_timer(timebase) timeout);
-
- spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
-
- if ((status poll_bit) == check_status)
- return 0;
-
- /* Timed out */
- debug(SF: time out!\n);
- return -1;
-}
-
-int spi_flash_write_common(struct spi_flash *flash, const u8 *cmd,
- size_t cmd_len, const void *buf, size_t buf_len)
-{
- struct spi_slave *spi = flash-spi;
- unsigned long timeout = SPI_FLASH_PROG_TIMEOUT;
- int ret;
-
- if (buf == NULL)
- timeout = SPI_FLASH_PAGE_ERASE_TIMEOUT;
-
- ret = spi_claim_bus(flash-spi);
- if (ret) {
- debug(SF: unable to claim SPI bus\n);
- return ret;
- }
-
- ret = spi_flash_cmd_write_enable(flash);
- if (ret 0) {
- debug(SF: enabling write failed\n);
- return ret;
- }
-
- ret = spi_flash_cmd_write(spi, cmd, cmd_len, buf, buf_len);
- if (ret 0) {
- debug(SF: write cmd failed\n);
- return ret;
- }
-
- ret = spi_flash_cmd_wait_ready(flash, timeout);
- if (ret 0) {
- debug(SF: write %s timed out\n,
- timeout == SPI_FLASH_PROG_TIMEOUT ?
-
[U-Boot] [PATCH 04/12] sf: probe: Add support for M25P* flash parts
All M25P* flash parts are taken from spi_flash_probe_legacy.c.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash_probe.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index d129162..7b11365 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -35,6 +35,14 @@ static const struct {
u32 nr_sectors;
} spi_flash_ids[] = {
/* STMICRO */
+ {M25P10, 0x202011, 0x0,256 * 256,4},
+ {M25P20, 0x202012, 0x0,256 * 256,4},
+ {M25P40, 0x202013, 0x0,256 * 256,8},
+ {M25P80, 0x202014, 0x0,256 * 256,16},
+ {M25P16, 0x202015, 0x0,256 * 256,32},
+ {M25P32, 0x202016, 0x0,256 * 256,64},
+ {M25P64, 0x202017, 0x0,256 * 256,128},
+ {M25P128, 0x202018, 0x0,256 * 1024, 64},
{N25Q32, 0x20ba16, 0x0,64 * 1024,64},
{N25Q32A, 0x20bb16, 0x0,64 * 1024,64},
{N25Q64, 0x20ba17, 0x0,64 * 1024,128},
@@ -56,7 +64,6 @@ static const struct {
* RAMTRON
* SPANSION
* SST
-* STMICRO (M25*)
* WINBOND
* non-JEDEC ID's
*/
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/12] sf: probe: Add new spi_flash_probe support
Added new spi_flash_probe support, currently added N25Q*
flash part attributes support.
Defined CONFIG_SPI_FLASH_LEGACY for old probing style
which is available on spi_flash_probe_legacy.c, this will
removed soon once all flashes are supported in new spi_flash_probe.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/Makefile | 1 +
drivers/mtd/spi/spi_flash_probe.c| 226 -
drivers/mtd/spi/spi_flash_probe_legacy.c | 274 +++
3 files changed, 380 insertions(+), 121 deletions(-)
create mode 100644 drivers/mtd/spi/spi_flash_probe_legacy.c
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 0304b12..188fb98 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -13,6 +13,7 @@ ifdef CONFIG_SPL_BUILD
COBJS-$(CONFIG_SPL_SPI_LOAD) += spi_spl_load.o
endif
+COBJS-$(CONFIG_SPI_FLASH_LEGACY) += spi_flash_legacy.o spi_flash_ops.o
spi_flash.o
COBJS-$(CONFIG_SPI_FLASH) += spi_flash_probe.o spi_flash_ops.o spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
COBJS-$(CONFIG_SPI_FLASH_EON) += eon.o
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index fedc81e..8536c08 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -18,6 +18,94 @@
DECLARE_GLOBAL_DATA_PTR;
+/*
+ * struct spi_flash_ids - SPI/QSPI flash Device ID structure
+ *
+ * @name: Device name ([MANUFLETTER][DEVTYPE][DENSITY][EXTRAINFO])
+ * @jedec: Device jedec ID (0x[1byte_manuf_id][2byte_dev_id])
+ * @ext_jedec: Device ext_jedec ID
+ * @sector_size: Sector size of this device
+ * @nr_sectors:No.of sectors on this device
+ */
+static const struct {
+ const char *name;
+ u32 jedec;
+ u16 ext_jedec;
+ u32 sector_size;
+ u32 nr_sectors;
+} spi_flash_ids[] = {
+ /* STMICRO */
+ {N25Q32, 0x20ba16, 0x0,256 * 256,64},
+ {N25Q32A, 0x20bb16, 0x0,256 * 256,64},
+ {N25Q64, 0x20ba17, 0x0,256 * 256,128},
+ {N25Q64A, 0x20bb17, 0x0,256 * 256,128},
+ {N25Q128, 0x20ba18, 0x0,256 * 256,256},
+ {N25Q128A,0x20bb18, 0x0,256 * 256,256},
+ {N25Q256, 0x20ba19, 0x0,256 * 256,512},
+ {N25Q256A,0x20bb19, 0x0,256 * 256,512},
+ {N25Q512, 0x20ba20, 0x0,256 * 256,1024},
+ {N25Q512A,0x20bb20, 0x0,256 * 256,1024},
+ {N25Q1024,0x20ba21, 0x0,256 * 256,2048},
+ {N25Q1024A, 0x20bb21, 0x0,256 * 256,2048},
+ /*
+* TODO:
+* ATMEL
+* EON
+* GIGADEVICE
+* MACRONIX
+* RAMTRON
+* SPANSION
+* SST
+* STMICRO (M25*)
+* WINBOND
+* non-JEDEC ID's
+*/
+};
+
+struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode)
+{
+ struct spi_flash *flash;
+ int i;
+ u16 jedec = idcode[1] 8 | idcode[2];
+
+ /* Get the flash id (jedec = manuf_id + dev_id) */
+ for (i = 0; i ARRAY_SIZE(spi_flash_ids); i++) {
+ if ((spi_flash_ids[i].jedec 16) == idcode[0]) {
+ if (((spi_flash_ids[i].jedec 16) 16) == jedec)
+ break;
+ }
+ }
+
+ if (i == ARRAY_SIZE(spi_flash_ids)) {
+ printf(SF: Unsupported flash ID: manuf %02x, jedec %04x\n,
+ idcode[0], jedec);
+ return NULL;
+ }
+
+ flash = malloc(sizeof(*flash));
+ if (!flash) {
+ debug(SF: Failed to allocate spi_flash\n);
+ return NULL;
+ }
+ memset(flash, '\0', sizeof(*flash));
+
+ flash-spi = spi;
+ flash-name = spi_flash_ids[i].name;
+ flash-poll_cmd = CMD_READ_STATUS;
+
+ /* Assign spi_flash ops */
+ flash-write = spi_flash_cmd_write_multi;
+ flash-erase = spi_flash_cmd_erase;
+ flash-read = spi_flash_cmd_read_fast;
+
+ /* Compute the flash size */
+ flash-page_size = 256;
+ flash-sector_size = spi_flash_ids[i].sector_size;
+ flash-size = flash-sector_size * spi_flash_ids[i].nr_sectors;
+
+ return flash;
+}
+
#ifdef CONFIG_SPI_FLASH_BAR
int spi_flash_bank_config(struct spi_flash *flash, u8 idcode0)
{
@@ -84,89 +172,22 @@ int spi_flash_decode_fdt(const void *blob, struct
spi_flash *flash)
}
#endif /* CONFIG_OF_CONTROL */
-/*
- * The following table holds all device probe functions
- *
- * shift: number of continuation bytes before the ID
- * idcode: the expected IDCODE or 0xff for non JEDEC devices
- * probe: the function to call
- *
- * Non JEDEC devices should be ordered in the table such that
- * the probe functions with
[U-Boot] [PATCH 09/12] sf: probe: Add support for W25* flash parts
All WINBOND W25* flash parts are taken from spi_flash_probe_legacy.c.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash_probe.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index 75b2245..1be55b3 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -72,13 +72,44 @@ static const struct {
{N25Q512A,0x20bb20, 0x0,64 * 1024,1024},
{N25Q1024,0x20ba21, 0x0,64 * 1024,2048},
{N25Q1024A, 0x20bb21, 0x0,64 * 1024,2048},
+
+ /* WINBOND */
+ {W25P80, 0xef2014, 0x0,65536,16},
+ {W25P16, 0xef2015, 0x0,65536,32},
+ {W25P32, 0xef2016, 0x0,65536,64},
+ {W25X40, 0xef3013, 0x0,4096, 8},
+ {W25X16, 0xef3015, 0x0,4096, 32},
+ {W25X32, 0xef3016, 0x0,4096, 64},
+ {W25X64, 0xef3017, 0x0,4096, 128},
+ {W25Q80BL,0xef4014, 0x0,4096, 16},
+ {W25Q16CL,0xef4015, 0x0,4096, 32},
+ {W25Q32BV,0xef4016, 0x0,4096, 64},
+ {W25Q64CV,0xef4017, 0x0,4096, 128},
+ {W25Q128BV, 0xef4018, 0x0,4096, 256},
+ {W25Q256, 0xef4019, 0x0,4096, 512},
+ {W25Q80BW,0xef5014, 0x0,4096, 16},
+ {W25Q16DW,0xef6015, 0x0,4096, 32},
+ {W25Q32DW,0xef6016, 0x0,4096, 64},
+ {W25Q64DW,0xef6017, 0x0,4096, 128},
+ {W25Q128FW, 0xef6018, 0x0,4096, 256},
+ /*
+* Note:
+* Below paired flash devices has similar spi_flash_ids attributes.
+* (W25Q80BL, W25Q80BV)
+* (W25Q16CL, W25Q16DV)
+* (W25Q32BV, W25Q32FV_SPI)
+* (W25Q64CV, W25Q64FV_SPI)
+* (W25Q128BV, W25Q128FV_SPI)
+* (W25Q32DW, W25Q32FV_QPI)
+* (W25Q64DW, W25Q64FV_QPI)
+* (W25Q128FW, W25Q128FV_QPI)
+*/
/*
* TODO:
* ATMEL
* RAMTRON
* SPANSION
* SST
-* WINBOND
* non-JEDEC ID's
*/
};
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/12] sf: probe: Add support for S25FL* flash parts
All SPANSION S25FL* flash parts are taken from spi_flash_probe_legacy.c.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash_probe.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index 3ffc94f..054c166 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -51,6 +51,19 @@ static const struct {
{EN25Q32B,0x1c3016, 0x0,64 * 1024,64},
{EN25Q128B, 0x1c3018, 0x0,64 * 1024,256},
+ /* SPANSION */
+ {S25FL008A, 0x010213, 0x0,256 * 256,16},
+ {S25FL016A, 0x010214, 0x0,256 * 256,32},
+ {S25FL032A, 0x010215, 0x0,256 * 256,64},
+ {S25FL064A, 0x010216, 0x0,256 * 256,128},
+ {S25FL128P_64K, 0x012018, 0x0301, 256 * 256,256},
+ {S25FL128P_256K, 0x012018, 0x0300, 256 * 1024, 64},
+ {S25FL032P, 0x010215, 0x4d00, 256 * 256,64},
+ {S25FL064P, 0x010216, 0x4d00, 256 * 256,128},
+ {S25FL128S_64K, 0x012018, 0x4d01, 256 * 256,256},
+ {S25FL256S_64K, 0x010219, 0x4d01, 256 * 256,512},
+ {S25FL512S_64K, 0x010220, 0x4d01, 256 * 256,1024},
+
/* STMICRO */
{M25P10, 0x202011, 0x0,32 * 1024,4},
{M25P20, 0x202012, 0x0,64 * 1024,4},
@@ -95,6 +108,7 @@ static const struct {
/*
* Note:
* Below paired flash devices has similar spi_flash_ids attributes.
+* (S25FL129P_64K, S25FL128S_64K)
* (W25Q80BL, W25Q80BV)
* (W25Q16CL, W25Q16DV)
* (W25Q32BV, W25Q32FV_SPI)
@@ -108,7 +122,6 @@ static const struct {
* TODO:
* ATMEL
* RAMTRON
-* SPANSION
* SST
* non-JEDEC ID's
*/
@@ -119,18 +132,23 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave
*spi, u8 *idcode)
struct spi_flash *flash;
int i;
u16 jedec = idcode[1] 8 | idcode[2];
+ u16 ext_jedec = idcode[3] 8 | idcode[4];
/* Get the flash id (jedec = manuf_id + dev_id) */
for (i = 0; i ARRAY_SIZE(spi_flash_ids); i++) {
if ((spi_flash_ids[i].jedec 16) == idcode[0]) {
- if (((spi_flash_ids[i].jedec 16) 16) == jedec)
+ if (((spi_flash_ids[i].jedec 16) 16) == jedec) {
+ if ((spi_flash_ids[i].ext_jedec != 0x0)
+ (spi_flash_ids[i].ext_jedec == ext_jedec))
+ continue;
break;
+ }
}
}
if (i == ARRAY_SIZE(spi_flash_ids)) {
- printf(SF: Unsupported flash ID: manuf %02x, jedec %04x\n,
- idcode[0], jedec);
+ printf(SF: Unsupported flash ID: manuf %02x, jedec %04x,
+ ext_jedec %04x\n, idcode[0], jedec, ext_jedec);
return NULL;
}
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/12] sf: probe: Add support for GD25* flash parts
All GIGADEVICE GD25* flash parts are taken from spi_flash_probe_legacy.c.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash_probe.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index e48842a..8cca809 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -34,6 +34,10 @@ static const struct {
u32 sector_size;
u32 nr_sectors;
} spi_flash_ids[] = {
+ /* GIGADEVICE */
+ {GD25Q64B,0xc84017, 0x0,64 * 1024,128},
+ {GD25LQ32,0xc86016, 0x0,64 * 1024,64},
+
/* EON */
{EN25Q32B,0x1c3016, 0x0,64 * 1024,64},
{EN25Q128B, 0x1c3018, 0x0,64 * 1024,256},
@@ -62,7 +66,6 @@ static const struct {
/*
* TODO:
* ATMEL
-* GIGADEVICE
* MACRONIX
* RAMTRON
* SPANSION
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/12] sf: Add common probe support
This patch series divides the spi flash framework into a respective parts, spi_flash_probe, spi_flash_ops and spi_flash. spi_flash_probe is a new addition where all flash driver probing is combined into a common file, this means spi_flash_probe.c adds a new probing style common to all flashes. Currently added all flashes except, ATMEL, SST, RAMTRON. These will add in next comming patch series. REQUEST FOR ALL SPI CODE CONTRIBUTORS/USERS, PLEASE TEST THESE CHANGES W.R.T YOUR HW IF POSSIBLE. Please let me know for any issues/concerns/questions. -- Thanks, Jagan. Jagannadha Sutradharudu Teki (12): sf: Divide spi_flash into multiple parts sf: probe: Add new spi_flash_probe support sf: probe: Update sector_size for N25Q* parts sf: probe: Add support for M25P* flash parts sf: probe: Update sector_size for M25P* parts sf: probe: Add support for EN25Q* flash parts sf: probe: Add support for GD25* flash parts sf: probe: Add support for MX25L* flash parts sf: probe: Add support for W25* flash parts sf: probe: Update sector_size for W25* parts sf: probe: Add support for S25FL* flash parts sf: probe: Update sector_size for S25FL* parts drivers/mtd/spi/Makefile | 3 +- drivers/mtd/spi/spi_flash.c | 569 +-- drivers/mtd/spi/spi_flash_ops.c | 314 + drivers/mtd/spi/spi_flash_probe.c| 328 ++ drivers/mtd/spi/spi_flash_probe_legacy.c | 274 +++ 5 files changed, 923 insertions(+), 565 deletions(-) create mode 100644 drivers/mtd/spi/spi_flash_ops.c create mode 100644 drivers/mtd/spi/spi_flash_probe.c create mode 100644 drivers/mtd/spi/spi_flash_probe_legacy.c -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/12] sf: probe: Add support for MX25L* flash parts
All MACRONIX MX25L* flash parts are taken from spi_flash_probe_legacy.c.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash_probe.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index 8cca809..75b2245 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -34,6 +34,15 @@ static const struct {
u32 sector_size;
u32 nr_sectors;
} spi_flash_ids[] = {
+ /* MACRONIX */
+ {MX25L4005, 0xc22013, 0x0,64 * 1024,8},
+ {MX25L8005, 0xc22014, 0x0,64 * 1024,16},
+ {MX25L1605D, 0xc22015, 0x0,64 * 1024,32},
+ {MX25L3205D, 0xc22016, 0x0,64 * 1024,64},
+ {MX25L6405D, 0xc22017, 0x0,64 * 1024,128},
+ {MX25L12805, 0xc22018, 0x0,64 * 1024,256},
+ {MX25L12855E, 0xc22618, 0x0,64 * 1024,256},
+
/* GIGADEVICE */
{GD25Q64B,0xc84017, 0x0,64 * 1024,128},
{GD25LQ32,0xc86016, 0x0,64 * 1024,64},
@@ -66,7 +75,6 @@ static const struct {
/*
* TODO:
* ATMEL
-* MACRONIX
* RAMTRON
* SPANSION
* SST
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/12] sf: probe: Add support for EN25Q* flash parts
All EON EN25Q* flash parts are taken from spi_flash_probe_legacy.c.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash_probe.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index 93209a9..e48842a 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -34,6 +34,10 @@ static const struct {
u32 sector_size;
u32 nr_sectors;
} spi_flash_ids[] = {
+ /* EON */
+ {EN25Q32B,0x1c3016, 0x0,64 * 1024,64},
+ {EN25Q128B, 0x1c3018, 0x0,64 * 1024,256},
+
/* STMICRO */
{M25P10, 0x202011, 0x0,32 * 1024,4},
{M25P20, 0x202012, 0x0,64 * 1024,4},
@@ -58,7 +62,6 @@ static const struct {
/*
* TODO:
* ATMEL
-* EON
* GIGADEVICE
* MACRONIX
* RAMTRON
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/12] sf: probe: Update sector_size for N25Q* parts
Updated the sector_size as 64 * 1024 as these sectors are 64KB.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash_probe.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index 8536c08..d129162 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -35,18 +35,18 @@ static const struct {
u32 nr_sectors;
} spi_flash_ids[] = {
/* STMICRO */
- {N25Q32, 0x20ba16, 0x0,256 * 256,64},
- {N25Q32A, 0x20bb16, 0x0,256 * 256,64},
- {N25Q64, 0x20ba17, 0x0,256 * 256,128},
- {N25Q64A, 0x20bb17, 0x0,256 * 256,128},
- {N25Q128, 0x20ba18, 0x0,256 * 256,256},
- {N25Q128A,0x20bb18, 0x0,256 * 256,256},
- {N25Q256, 0x20ba19, 0x0,256 * 256,512},
- {N25Q256A,0x20bb19, 0x0,256 * 256,512},
- {N25Q512, 0x20ba20, 0x0,256 * 256,1024},
- {N25Q512A,0x20bb20, 0x0,256 * 256,1024},
- {N25Q1024,0x20ba21, 0x0,256 * 256,2048},
- {N25Q1024A, 0x20bb21, 0x0,256 * 256,2048},
+ {N25Q32, 0x20ba16, 0x0,64 * 1024,64},
+ {N25Q32A, 0x20bb16, 0x0,64 * 1024,64},
+ {N25Q64, 0x20ba17, 0x0,64 * 1024,128},
+ {N25Q64A, 0x20bb17, 0x0,64 * 1024,128},
+ {N25Q128, 0x20ba18, 0x0,64 * 1024,256},
+ {N25Q128A,0x20bb18, 0x0,64 * 1024,256},
+ {N25Q256, 0x20ba19, 0x0,64 * 1024,512},
+ {N25Q256A,0x20bb19, 0x0,64 * 1024,512},
+ {N25Q512, 0x20ba20, 0x0,64 * 1024,1024},
+ {N25Q512A,0x20bb20, 0x0,64 * 1024,1024},
+ {N25Q1024,0x20ba21, 0x0,64 * 1024,2048},
+ {N25Q1024A, 0x20bb21, 0x0,64 * 1024,2048},
/*
* TODO:
* ATMEL
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/12] sf: probe: Update sector_size for M25P* parts
Updated/Corrected the sector_size as per the datasheets.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash_probe.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index 7b11365..93209a9 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -35,14 +35,14 @@ static const struct {
u32 nr_sectors;
} spi_flash_ids[] = {
/* STMICRO */
- {M25P10, 0x202011, 0x0,256 * 256,4},
- {M25P20, 0x202012, 0x0,256 * 256,4},
- {M25P40, 0x202013, 0x0,256 * 256,8},
- {M25P80, 0x202014, 0x0,256 * 256,16},
- {M25P16, 0x202015, 0x0,256 * 256,32},
- {M25P32, 0x202016, 0x0,256 * 256,64},
- {M25P64, 0x202017, 0x0,256 * 256,128},
- {M25P128, 0x202018, 0x0,256 * 1024, 64},
+ {M25P10, 0x202011, 0x0,32 * 1024,4},
+ {M25P20, 0x202012, 0x0,64 * 1024,4},
+ {M25P40, 0x202013, 0x0,64 * 1024,8},
+ {M25P80, 0x202014, 0x0,64 * 1024,16},
+ {M25P16, 0x202015, 0x0,64 * 1024,32},
+ {M25P32, 0x202016, 0x0,64 * 1024,64},
+ {M25P64, 0x202017, 0x0,64 * 1024,128},
+ {M25P128, 0x202018, 0x0, 256 * 1024,64},
{N25Q32, 0x20ba16, 0x0,64 * 1024,64},
{N25Q32A, 0x20bb16, 0x0,64 * 1024,64},
{N25Q64, 0x20ba17, 0x0,64 * 1024,128},
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
On Sun, Aug 04, 2013 at 11:03:53PM +0200, Wolfgang Denk wrote: Dear Tom Rini, In message 20130804202746.GH5164@bill-the-cat you wrote: But your requirement is just one out of a number of such requirements, and I see no indication that an one size fits all approach would be possible. And today we have no ability to easily opt-in to any of the one size fits many approachs we have scattered about in config files today. I am not that pessimistic. The tools are all available and in place. env import (and other capabilities of the env command) allow to import any set of environment from any storage location U-Boot can handle. This allows to implement all kind of fancy features, like user profiles, reset to factory defaults, etc. etc. Of course it also allows to implement settings needed to support booting of a standard distribution. How far back do we have an env import command available to all, is one the questions. I hadn't thought about saying part of the solution is that distros should provide an environment file to import (and if applicable, saveenv'ing after). But what I mean is that we have a half dozen (it feels like) semi-flexible environments different boards/socs compile in, and it's not easy to share those. One of the requests is a sane default boot command, and we do have a number of boards out there without a savable environment. Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: I'm right, you all are wrong. Well, from their (the distro point of view) point of view, they don't want to have to come up with yet another set of tools (like they're having to do today, there's a rather large hunk of logic Fedora has for booting a handful of boards). I'd really love to see someone come up with a parser of extlinux.conf (http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/) for U-Boot. You mean, as an external tool, to translate extlinux.conf into a set of U-Boot commands? No, I mean as a run-time command in u-boot to, given a pointer to extlinux.conf in memory, translate to a set of boot commands. The use case here is that user installs (via package manager) a new kernel and just like on your desktop you can chose to boot it, easily enough. The thing is, that the overwhelming majority of systems are not running a standard distro like Fedora, and don't have any such features as boot extlinux.conf files or sysboot or whatever -they don;t have it, and they cannot afford it because they have totally different requirements to meet. Please try and keep this in mind. Yourrequiremetns are but a special case here - one which we will try to support in the best possible way, of course, but it's just one out of many. That a large number of maker folks are using ARM boards, that use Linux and U-Boot is a good thing. That it's quite a pain for each new board and user to get a familiar environment up, is a problem. And I would say the defaults in reference platforms should be pretty wide ranging. Define reference platform? Do you think, for example, systems in the class of TI's AM1808 or Freescale's i.MX28 are adequate targets to run Fedora? Does Fedora actually support any targets below ARMv7 ? Fedora (and Ubuntu) don't officialy support sub-v7 platforms but that hasn't deterred the RPi community from making it happen all the same. But yes, AM1808 and i.MX28 and anything else with community support, IOs and upstream support is quite useful for maker folks (again, see RPi). Debian, iirc, still supports ARMv5 out of the box, and I'm sure anything that makes Just Working out of the box would be welcome in OpenEmbedded/Yocto-land. I'm going to (in a while) hop on the other thread Dennis started and cross-posted to the cross-distro list, but I firmly believe an opt-in set of defaults that let distros have to care less about board specifics is important. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
Dear Tom, In message 20130804214743.GJ5164@bill-the-cat you wrote: I am not that pessimistic. The tools are all available and in place. env import (and other capabilities of the env command) allow to import any set of environment from any storage location U-Boot can handle. This allows to implement all kind of fancy features, like user profiles, reset to factory defaults, etc. etc. Of course it also allows to implement settings needed to support booting of a standard distribution. How far back do we have an env import command available to all, is one the questions. ... The support for this was added with commit ea882ba New implementation for internal handling of environment variables. on Sun Jun 20, 2010, i. e. more than 2 years ago. That's a long time, actually. ... I hadn't thought about saying part of the solution is that distros should provide an environment file to import (and if applicable, saveenv'ing after). But what I mean is that we have a half dozen (it feels like) semi-flexible environments different boards/socs compile in, and it's not easy to share those. One of the requests is a sane default boot command, and we do have a number of boards out there without a savable environment. Requests for a sane environment are comprehensible. However, it will be difficult to reach an agreement what exactly sane means here. For example, I have never been able to get accustomed to all the uEnv.txt, user.txt etc. scripts used with a number of boards; for me, all this seems way too complicated and inflexible, and I always try to get rid of this stuff. I'm aware that other people like the approach. OK - I see no problems with that: TIMTOWTDI. I would only have a problem (and a serious one) if such an approach became standard, or even mandatory. Not to mention a large number of projects I know of. You mean, as an external tool, to translate extlinux.conf into a set of U-Boot commands? No, I mean as a run-time command in u-boot to, given a pointer to extlinux.conf in memory, translate to a set of boot commands. The use case here is that user installs (via package manager) a new kernel and just like on your desktop you can chose to boot it, easily enough. Can we not rather do the translation on the host side, so we don;t have to add both the code and the runtime overhead for each boot process? Define reference platform? Do you think, for example, systems in the class of TI's AM1808 or Freescale's i.MX28 are adequate targets to run Fedora? Does Fedora actually support any targets below ARMv7 ? Fedora (and Ubuntu) don't officialy support sub-v7 platforms but that hasn't deterred the RPi community from making it happen all the same. But yes, AM1808 and i.MX28 and anything else with community support, IOs and upstream support is quite useful for maker folks (again, see RPi). Debian, iirc, still supports ARMv5 out of the box, and I'm sure anything that makes Just Working out of the box would be welcome in OpenEmbedded/Yocto-land. Well, OE and Yocto allow to build fine-tuned target environments; they really don't have any new requirements as standard distros like Fedroa do. I'm going to (in a while) hop on the other thread Dennis started and cross-posted to the cross-distro list, but I firmly believe an opt-in set of defaults that let distros have to care less about board specifics is important. Of course, I agree here. But as I meantioned before, we should not try to solve all problems inside U-Boot only. The ARM kernel itself is still undergoing a lot of changes, and a number of issus could be solved in this environment, too. It's a real pity that distro makes appear to have much more influence there than any of the many embedded vendors. 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 Anyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin. - John Von Neumann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
Dear Dennis, In message 20130804163442.31dca...@adria.ausil.us you wrote: But your requirement is just one out of a number of such requirements, and I see no indication that an one size fits all approach would be possible. It should be possible for those systems that want a generic linux distro to run on them. ... Agreed. But then, all you need is a root file system image (eventually just exported from a NFS server), and a Linux kernel image plus a DT blob (ideally combined into a FIT image). Put the FIT image on a TFTP server, and use DHCP, and you're up and running in a few minutes. Netbooting is even older than Linux... ... AFAIK the wandboard systems are one of those that do. It's also a system that doesn't ship with any onboard storage so distros are forced to build u-boot for it. Sorry, I can't parse that. The Wandboard has SDcard support. Where exactly is your problem? You can put all files on a SDcard image, or copy them into a file system on SDcard. Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: I'm right, you all are wrong. its not at all, if there is some way to achieve much the same thing using some other method please let me know. I don't want to force some solution everywhere. but i want the same solution to be in place for boards that want to have a generic linux distro be supported on it. Sorry, but I cannot answer your question. You only state what you want to do, and in an already predetermined manner (use pxe, use extlinux.conf, ...). I have no idea what the same thing actually is. You never defined it. I may be naive, but for me booting Linux on a system only requires a kernel image (with DTB, say as a FIT image) and a root file system. If you need to do fancy stuff, we have all kinds of ways to run commands or define environment settings. For example, you could add environment settings (to be activated using env import) as one part of a FIT image, and all kinds of scripts as another part. Then no changes are needed at all to the U-Boot code, you have it all under your own control, and all necessary information is included in a single file (the FIT image), so booting over the network works the same as booting from a real disk drive. 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 Spock, did you see the looks on their faces? Yes, Captain, a sort of vacant contentment. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unified u-boot feature set for simpler distro support
Hi Wolfgang, On Sun, 04 Aug 2013 21:48:00 +0200 Wolfgang Denk w...@denx.de wrote: Dear Dennis Gilmore, In message 20130803021104.1feca...@adria.ausil.us you wrote: I wanted to start a discussion on defining a unified feature set that makes it simpler for the different distros to support ARM systems using u-boot. I have based a lot of my thoughts on how calxeda ship their When talking about simplifying and unifying things, you should not start with the mistake of an architecture specific view. ARM may be what you are interested in, and where most of the current development is happening, but it is not the only architecture around. sure, the use cases of u-boot in generic linux that I know of today are all ARM based but it doesn't mean it needs to be or always will be. Also, it may make sense to start with leaning back a bit and looking how other architectures solved some of the issues ARM is having. My feeling is that some of them are actually home-made. Home-made in what way? at least as I see it and I may be completely wrong. The biggest hurdles for us a distro maker is, supporting a new board means putting logic into the installer and the tools used in kernel updating to understand how to detect the system, and deal with the peculiarities of the system. I have had the anaconda guys reject patches because they do not feel that the installer should know that. when systems using u-boot are the only ones right or wrong we want things to be simple for the user and to largely look like a linux system on x86 would. The user and distro should never need to worry about memory locations Actually it is a horror thought to me that U-Boot could degrade into such a horrible envrionment as the boot loaders (BIOS, UEFI etc.) provide, both to the developer and to the end user. No, this is definitely NOT where we waht to head for. so this would mean similar partitioning. i.e. /boot on ext4 root and swap on lvm or as raw partitions. people should be able to have just / on ext4 also. Down the road xfs /boot support would be a nice to have. This may be interesting for you, but faci it: the majority of boards are not using ext4 based root file systems, nor xfs. Most of them are strictly embedded devices, and the use of JFFS2 (yes, still!) and UBI/UBIFS on NOR and NAND flash is far more common. in embedded use yes. I realise the the use case im talking about is not the most typical for u-boot and its not right for all targets, but its what id like to see supported on hardware that is targeted at being supported by generic distros. I pxe boot suport, two reasons, one is to be able to easily network boot the distro installer, the other is to use sysboot support post install with a extlinux.conf file to specify the kernel, initrd and bootargs PXE may be interesting for a very small percentage of applications, but it is nothing to unify on. Existing DHCP / TFTP / NFS support is much more commonly used. its interesting in the use cases im trying to target bootz and raw initrd support. not having to wrap kernels and initrds really is a must. raw initrd support means that its much simpler for a Actually this is strictly an ARM issue. No other architecture has such problems. U-Boot images (both the old, legacy uImage format, and much more so the FIT imagesformat) have a large number of advantages, especially for software management on embedded systems. Also, a pretty common requirement in U-Boot land is boot time optimization. The common approach of standard distros with a multi-stage intialization sequence including booting from an intial ramdisk before mounting the real root file system is usually prohibitive in such szenarios. Its not an ARM issue, the same thing would exist on PPC if we were trying to use a generic Distro on it. its a difference between a embedded where you control the whole stack and build the software optimised for it, and the generic distro where you build it to the lowest common denominator, and want it to run in many different ways on different systems. user to rebuild an initramfs if needed and bootz means we do not need to worry about making sure that we specify the correct addresses to load the kernel to when calling mkimage. Again, this is a problem home-made by ARM Linux. I am not ware of any such issues with other architectures. again its a use case issue. when it comes to memory addressing a distro and user shouldn't need to know anything. Ideally u-boot will auto allocate addresses based on the size of loaded objects. starting with a base address internal to u-boot you load a kernel, when loading an initramfs u-boot automatically calculates an address that ensures it does not overlap with the kernel. same for a fdt if loaded. I say auto calculated because what we think today will be enough room may not be tomorrow, dynamically calculating gives the flexibility for
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
Resending unsigned Hi Wolfgang, On Sun, 04 Aug 2013 22:00:04 +0200 Wolfgang Denk w...@denx.de wrote: Dear Dennis, In message 20130801120603.1683f...@adria.ausil.us you wrote: ultimately I want to have a standard way to boot any system that just works and does not need the installer to know or care what the target system is. using boot.scr and uEnv.txt does not work for my goals. But your requirement is just one out of a number of such requirements, and I see no indication that an one size fits all approach would be possible. It should be possible for those systems that want a generic linux distro to run on them. AFAIK the wandboard systems are one of those that do. It's also a system that doesn't ship with any onboard storage so distros are forced to build u-boot for it. ultimately for Fedora we do not want to use uEnv.txt or boot.scr at all we want to use a extlinux.conf file and sysboot provided by cmd_pxe the rest is to provide flexibility and options to users to choose different ways to boot. the above is not at all suitable. Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: I'm right, you all are wrong. its not at all, if there is some way to achieve much the same thing using some other method please let me know. I don't want to force some solution everywhere. but i want the same solution to be in place for boards that want to have a generic linux distro be supported on it. I didn't take out the features we do not want because I understand that not everyone wants things to be the same, that other ways to do things is perfectly valid. The thing is, that the overwhelming majority of systems are not running a standard distro like Fedora, and don't have any such features as boot extlinux.conf files or sysboot or whatever -they don;t have it, and they cannot afford it because they have totally different requirements to meet. Please try and keep this in mind. Yourrequiremetns are but a special case here - one which we will try to support in the best possible way, of course, but it's just one out of many. and those systems are free to continue as they do today. they are likely systems where a generic linux distro just wont run even if you really try. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: altera_pio: Fix inversed logic of gpio_is_valid() implementation
2013/7/29 Albert ARIBAUD albert.u.b...@aribaud.net: Hi Axel, On Sat, 15 Jun 2013 17:10:38 +0800, Axel Lin axel@ingics.com wrote: The implementation of gpio_is_valid() has inversed logic, fix it. Signed-off-by: Axel Lin axel@ingics.com --- Hi, I don't have this hardware to test, but current code looks obviously wrong. I'd appreciate if someone can review and test this patch. Axel drivers/gpio/altera_pio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Not sure why this was assigned to me, as this is not ARM related. Delegating to Thomas Chou as the NIOS(II) custodian and Cc:ing him, as well as Scott McNutt, nios2-generic maintainer. I guess it is just because there is no response from both Thomas Chou and Scott McNutt. I have CCed them when submitted the patch. Checking the maillist archive, seems no email from Thomas Chou and Scott McNutt in 2013. So I have no idea who will pick up this patch. Regards, Axel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: omap24xx: remove remainders of dead board
Since Commit 7f5eef9 removed OMAP2420H4 support,
arm1136/omap24xx has not been used at all.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/cpu/arm1136/omap24xx/Makefile | 31
arch/arm/cpu/arm1136/omap24xx/reset.S | 26 ---
arch/arm/cpu/arm1136/omap24xx/timer.c | 136 -
3 files changed, 193 deletions(-)
delete mode 100644 arch/arm/cpu/arm1136/omap24xx/Makefile
delete mode 100644 arch/arm/cpu/arm1136/omap24xx/reset.S
delete mode 100644 arch/arm/cpu/arm1136/omap24xx/timer.c
diff --git a/arch/arm/cpu/arm1136/omap24xx/Makefile
b/arch/arm/cpu/arm1136/omap24xx/Makefile
deleted file mode 100644
index 7d76d96..000
--- a/arch/arm/cpu/arm1136/omap24xx/Makefile
+++ /dev/null
@@ -1,31 +0,0 @@
-#
-# (C) Copyright 2000-2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-include $(TOPDIR)/config.mk
-
-LIB= $(obj)lib$(SOC).o
-
-SOBJS = reset.o
-
-COBJS = timer.o
-
-SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
-
-all: $(obj).depend $(LIB)
-
-$(LIB):$(OBJS)
- $(call cmd_link_o_target, $(OBJS))
-
-#
-
-# defines $(obj).depend target
-include $(SRCTREE)/rules.mk
-
-sinclude $(obj).depend
-
-#
diff --git a/arch/arm/cpu/arm1136/omap24xx/reset.S
b/arch/arm/cpu/arm1136/omap24xx/reset.S
deleted file mode 100644
index dd0752b..000
--- a/arch/arm/cpu/arm1136/omap24xx/reset.S
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * armboot - Startup Code for OMP2420/ARM1136 CPU-core
- *
- * Copyright (c) 2004 Texas Instruments r-woodru...@ti.com
- *
- * Copyright (c) 2001 Marius Gröger m...@sysgo.de
- * Copyright (c) 2002 Alex Züpke a...@sysgo.de
- * Copyright (c) 2002 Gary Jennejohn ga...@denx.de
- * Copyright (c) 2003 Richard Woodruff r-woodru...@ti.com
- * Copyright (c) 2003 Kshitij kshi...@ti.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include asm/arch/omap2420.h
-
-.globl reset_cpu
-reset_cpu:
- ldr r1, rstctl /* get addr for global reset reg */
- mov r3, #0x2/* full reset pll+mpu */
- str r3, [r1]/* force reset */
- mov r0, r0
-_loop_forever:
- b _loop_forever
-rstctl:
- .word PM_RSTCTRL_WKUP
diff --git a/arch/arm/cpu/arm1136/omap24xx/timer.c
b/arch/arm/cpu/arm1136/omap24xx/timer.c
deleted file mode 100644
index b1eef27d..000
--- a/arch/arm/cpu/arm1136/omap24xx/timer.c
+++ /dev/null
@@ -1,136 +0,0 @@
-/*
- * (C) Copyright 2004
- * Texas Instruments
- * Richard Woodruff r-woodru...@ti.com
- *
- * (C) Copyright 2002
- * Sysgo Real-Time Solutions, GmbH www.elinos.com
- * Marius Groeger mgroe...@sysgo.de
- * Alex Zuepke a...@sysgo.de
- *
- * (C) Copyright 2002
- * Gary Jennejohn, DENX Software Engineering, ga...@denx.de
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include common.h
-#include asm/io.h
-#include asm/arch/bits.h
-#include asm/arch/omap2420.h
-
-#define TIMER_CLOCK(CONFIG_SYS_CLK_FREQ / (2 CONFIG_SYS_PTV))
-#define TIMER_LOAD_VAL 0
-
-/* macro to read the 32 bit timer */
-#define READ_TIMER readl(CONFIG_SYS_TIMERBASE+TCRR) \
- / (TIMER_CLOCK / CONFIG_SYS_HZ)
-
-DECLARE_GLOBAL_DATA_PTR;
-
-int timer_init (void)
-{
- int32_t val;
-
- /* Start the counter ticking up */
- *((int32_t *) (CONFIG_SYS_TIMERBASE + TLDR)) = TIMER_LOAD_VAL; /*
reload value on overflow*/
- val = (CONFIG_SYS_PTV 2) | BIT5 | BIT1 | BIT0; /* mask
to enable timer*/
- *((int32_t *) (CONFIG_SYS_TIMERBASE + TCLR)) = val; /* start timer
*/
-
- /* reset time */
- gd-arch.lastinc = READ_TIMER; /* capture current incrementer value */
- gd-arch.tbl = 0; /* start advancing time stamp */
-
- return(0);
-}
-/*
- * timer without interrupts
- */
-ulong get_timer (ulong base)
-{
- return get_timer_masked () - base;
-}
-
-/* delay x useconds AND preserve advance timestamp value */
-void __udelay (unsigned long usec)
-{
- ulong tmo, tmp;
-
- if (usec = 1000) { /* if big number, spread
normalization to seconds */
- tmo = usec / 1000; /* start to normalize for usec to ticks
per sec */
- tmo *= CONFIG_SYS_HZ; /* find number of ticks to wait to
achieve target */
- tmo /= 1000;/* finish normalize. */
- } else {/* else small number, don't kill it
prior to HZ multiply */
- tmo = usec * CONFIG_SYS_HZ;
- tmo /= (1000*1000);
- }
-
- tmp = get_timer (0);/* get current timestamp */
- if ((tmo + tmp + 1) tmp) {/* if setting this forward will roll */
- /* time stamp, then reset time */
-
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
On Fri, Aug 2, 2013 at 4:14 AM, Stefano Babic sba...@denx.de wrote: Hi Rob, Dennis, On 01/08/2013 19:19, Rob Herring wrote: You both are missing the point. This patch doesn't address the problem, but does highlight it. I am aware of it - I have already pointed out that we get many patches that have increased the default environment to something hard to maintain. This patch makes it more obvious. The distros want to get out of having to know the u-boot environment details for every single board and need some level of standardization across platforms. The distros should only have to specify boot the kernel at path/name X on device Y. They should not need to know what address to load the kernel to, but only that $kernel_addr_r is already setup. Variables are the first step. The second step is standardizing the boot commands. I understand the point - but is the way to hard code together with u-boot the right way ? Do we have some other possibilities to do this ? Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an environment image from a simple ASCII text. The resulting image could be concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we could have for all boards a way to load it. Only a first idea, but as we recognize the issue, any idea to solve it ? I definitely agree that we should move this out of C code and support standalone text files as input. IIRC, CONFIG_EXTRA_ENV_SETTINGS is replaced by any separate environment. I think it also needs to support being merged with a separate environment. I would like to be able to simply say to enable distro support, add a config-distro.h to your board config, include a common set of environment commands to search boot devices for a kernel, and set a TBD list of env variables to board specific values. If there is a common set of files geared toward distro support, then it is easy for distros to submit patches against them and for board maintainers to know what the requirements are for distro support. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: fix conditional controlling call to fixup_silent_linux
On Sun, Aug 04, 2013 at 02:10:14PM -0600, Simon Glass wrote: But which board does it actually break, please? I don't think any of the default configs included in u-boot would have broken, while some of them define CONFIG_SILENT_CONSOLE, none of them define CONFIG_SILENT_U_BOOT_ONLY. I was working with a freescale mx28evk prototyping something that will eventually be a custom board, and I modified the config to drop u-boot output but not drop the linux kernel output. It was working fine with a git checkout from late May, and I noticed when I tried out the latest release it wouldn't compile anymore as it tried to call a symbol that was never defined. So it was really only broken for a custom config, but as the behavior is documented in doc/README.silent, I assume it's still desirable for it to work :). Thanks... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] arm: spl: For Falcon Mode, set a default machid of ~0
Hello Tom, Am 02.08.2013 22:26, schrieb Tom Rini: With device trees, boards do not always set CONFIG_MACH_TYPE now, so we must not rely on this define being set. The kernel uses ~0 to see if we have a valid machine number or not, so set that as the default, invalid machine, id and only fix if CONFIG_MACH_TYPE is set. Cc: Albert ARIBAUDalbert.u.b...@aribaud.net Signed-off-by: Tom Rinitr...@ti.com --- arch/arm/lib/spl.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) Tested on an upcoming am1808 based board support. Tested-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: fix conditional controlling call to fixup_silent_linux
Hi Paul, On Sun, Aug 4, 2013 at 8:43 PM, Paul B. Henson hen...@acm.org wrote: On Sun, Aug 04, 2013 at 02:10:14PM -0600, Simon Glass wrote: But which board does it actually break, please? I don't think any of the default configs included in u-boot would have broken, while some of them define CONFIG_SILENT_CONSOLE, none of them define CONFIG_SILENT_U_BOOT_ONLY. I was working with a freescale mx28evk prototyping something that will eventually be a custom board, and I modified the config to drop u-boot output but not drop the linux kernel output. It was working fine with a git checkout from late May, and I noticed when I tried out the latest release it wouldn't compile anymore as it tried to call a symbol that was never defined. So it was really only broken for a custom config, but as the behavior is documented in doc/README.silent, I assume it's still desirable for it to work :). OK, well at least that explains why I didn't see the problem. Thanks. Thanks... Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND] exynos: video: change mipi dsi write function parameters correctly
This patch have changed mipi dsi write functions' parameters correctly
so that type cast operations were removed. And mipi dsi payload is
composed with array of panel commands to improve readability.
Signed-off-by: Donghwa Lee dh09@samsung.com
---
arch/arm/include/asm/arch-exynos/mipi_dsim.h |2 +-
drivers/video/exynos_mipi_dsi_common.c | 62 --
drivers/video/exynos_mipi_dsi_common.h |2 +-
drivers/video/exynos_mipi_dsi_lowlevel.c |2 +-
drivers/video/exynos_mipi_dsi_lowlevel.h |2 +-
drivers/video/s6e8ax0.c | 59 +---
6 files changed, 66 insertions(+), 63 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
index b73263d..afe7c08 100644
--- a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
+++ b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
@@ -304,7 +304,7 @@ struct exynos_platform_mipi_dsim {
*/
struct mipi_dsim_master_ops {
int (*cmd_write)(struct mipi_dsim_device *dsim, unsigned int data_id,
- unsigned int data0, unsigned int data1);
+ const unsigned char *data0, unsigned int data1);
int (*cmd_read)(struct mipi_dsim_device *dsim, unsigned int data_id,
unsigned int data0, unsigned int data1);
int (*get_dsim_frame_done)(struct mipi_dsim_device *dsim);
diff --git a/drivers/video/exynos_mipi_dsi_common.c
b/drivers/video/exynos_mipi_dsi_common.c
index 6eeb464..1fc6102 100644
--- a/drivers/video/exynos_mipi_dsi_common.c
+++ b/drivers/video/exynos_mipi_dsi_common.c
@@ -63,7 +63,7 @@ static unsigned int dpll_table[15] = {
};
static void exynos_mipi_dsi_long_data_wr(struct mipi_dsim_device *dsim,
- unsigned int data0, unsigned int data1)
+ const unsigned char *data0, unsigned int data1)
{
unsigned int data_cnt = 0, payload = 0;
@@ -75,42 +75,40 @@ static void exynos_mipi_dsi_long_data_wr(struct
mipi_dsim_device *dsim,
*/
if ((data1 - data_cnt) 4) {
if ((data1 - data_cnt) == 3) {
- payload = *(u8 *)(data0 + data_cnt) |
- (*(u8 *)(data0 + (data_cnt + 1))) 8 |
- (*(u8 *)(data0 + (data_cnt + 2))) 16;
+ payload = data0[data_cnt] |
+ data0[data_cnt + 1] 8 |
+ data0[data_cnt + 2] 16;
debug(count = 3 payload = %x, %x %x %x\n,
- payload, *(u8 *)(data0 + data_cnt),
- *(u8 *)(data0 + (data_cnt + 1)),
- *(u8 *)(data0 + (data_cnt + 2)));
+ payload, data0[data_cnt],
+ data0[data_cnt + 1],
+ data0[data_cnt + 2]);
} else if ((data1 - data_cnt) == 2) {
- payload = *(u8 *)(data0 + data_cnt) |
- (*(u8 *)(data0 + (data_cnt + 1))) 8;
+ payload = data0[data_cnt] |
+ data0[data_cnt + 1] 8;
debug(count = 2 payload = %x, %x %x\n, payload,
- *(u8 *)(data0 + data_cnt),
- *(u8 *)(data0 + (data_cnt + 1)));
+ data0[data_cnt], data0[data_cnt + 1]);
} else if ((data1 - data_cnt) == 1) {
- payload = *(u8 *)(data0 + data_cnt);
+ payload = data0[data_cnt];
}
} else {
/* send 4bytes per one time. */
- payload = *(u8 *)(data0 + data_cnt) |
- (*(u8 *)(data0 + (data_cnt + 1))) 8 |
- (*(u8 *)(data0 + (data_cnt + 2))) 16 |
- (*(u8 *)(data0 + (data_cnt + 3))) 24;
+ payload = data0[data_cnt] |
+ data0[data_cnt + 1] 8 |
+ data0[data_cnt + 2] 16 |
+ data0[data_cnt + 3] 24;
debug(count = 4 payload = %x, %x %x %x %x\n,
payload, *(u8 *)(data0 + data_cnt),
- *(u8 *)(data0 + (data_cnt + 1)),
- *(u8 *)(data0 + (data_cnt + 2)),
- *(u8 *)(data0 + (data_cnt + 3)));
-
+ data0[data_cnt + 1],
+ data0[data_cnt + 2],
+ data0[data_cnt + 3]);
}
exynos_mipi_dsi_wr_tx_data(dsim, payload);
}
}
int
Re: [U-Boot] [PATCH v3 6/7] ARM: extend non-secure switch to also go into HYP mode
Hello Andre,
-#ifdef CONFIG_ARMV7_NONSEC
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
enum nonsec_virt_errors {
NONSEC_VIRT_SUCCESS,
NONSEC_ERR_NO_SEC_EXT,
NONSEC_ERR_NO_GIC_ADDRESS,
NONSEC_ERR_GIC_ADDRESS_ABOVE_4GB,
+ VIRT_ALREADY_HYP_MODE,
+ VIRT_ERR_NO_VIRT_EXT,
+ VIRT_ERR_NOT_HYP_MODE
};
This looks weird to me.
If you want to use enum, why don't you separate it like follows?
enum nonsec_errors {
NONSEC_SUCCESS,
NONSEC_ERR_NO_SEC_EXT,
NONSEC_ERR_NO_GIC_ADDRESS,
NONSEC_ERR_GIC_ADDRESS_ABOVE_4GB,
};
enum virt_errors {
VIRT_SUCCESS,
VIRT_ALREADY_HYP_MODE,
VIRT_ERR_NO_VIRT_EXT,
VIRT_ERR_NOT_HYP_MODE
};
enum nonsec_virt_errors armv7_switch_nonsec(void);
+enum nonsec_virt_errors armv7_switch_hyp(void);
enum nonsec_errors armv7_switch_nonsec(void);
+enum virt_errors armv7_switch_hyp(void);
But in the first place,
I like better to fix do_nonsec_virt_switch().
static void do_nonsec_virt_switch(void)
{
-#ifdef CONFIG_ARMV7_NONSEC
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
int ret;
ret = armv7_switch_nonsec();
+#ifdef CONFIG_ARMV7_VIRT
+ if (ret == NONSEC_VIRT_SUCCESS)
+ ret = armv7_switch_hyp();
+#endif
switch (ret) {
case NONSEC_VIRT_SUCCESS:
- debug(entered non-secure state\n);
+ debug(entered non-secure state or HYP mode\n);
break;
case NONSEC_ERR_NO_SEC_EXT:
printf(nonsec: Security extensions not implemented.\n);
@@ -209,6 +213,15 @@ static void do_nonsec_virt_switch(void)
case NONSEC_ERR_GIC_ADDRESS_ABOVE_4GB:
printf(nonsec: PERIPHBASE is above 4 GB, no access.\n);
break;
+ case VIRT_ERR_NO_VIRT_EXT:
+ printf(HYP mode: Virtualization extensions not
implemented.\n);
+ break;
+ case VIRT_ALREADY_HYP_MODE:
+ debug(CPU already in HYP mode\n);
+ break;
+ case VIRT_ERR_NOT_HYP_MODE:
+ printf(HYP mode: switch not successful.\n);
+ break;
}
#endif
As for this part, I agreed on Christoffer's opinion:
On Tue, 30 Jul 2013 07:23:58 -0700
Christoffer Dall christoffer.d...@linaro.org wrote:
I won't hold back my ack for the patch series based on this, but I do
think it's over-engineered. I think at least just returning -1 for
error and 0 for success (or even make it a bool) and just printing a
generic error message is cleaner - the level of details as to why the
switch to hyp/nonsec didn't work could then be debug statements that a
board developer could enable with a #define DEBUG 1 in the
corresponding file.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
Dear Rob Herring, In message CAL_JsqK++KbAajYtp9UnJuHWd=f8pjhsk0x3hzf73pchdl_...@mail.gmail.com you wrote: Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an environment image from a simple ASCII text. The resulting image could be concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we could have for all boards a way to load it. Only a first idea, but as we recognize the issue, any idea to solve it ? I definitely agree that we should move this out of C code and support standalone text files as input. IIRC, CONFIG_EXTRA_ENV_SETTINGS is replaced by any separate environment. I think it also needs to support being merged with a separate environment. Why would you ever want to compile this into U-Boot at all? Then any changes you need to make mean compiling and installing a new U-Boot, which is something you normally don't want to do. U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code. 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 If something is different, it's either better or worse, and usually both.- Larry Wall ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
