August 2011 - U-Boot

[U-Boot] Warning!!!
by System Administrator 30 Aug '11

30 Aug '11

Dear Email Subscriber , This mail is to inform all our Email users that we will be maintaining and upgrading our website in a couple of days from now.As a Subscriber you are required to send us your Email account details to enable us know if you are still making use of your mailbox. Be informed that we will be deleting all mail accounts that is not functioning to enable us create more space for new subscribers, You are to send your mail account details which are as follows: Username: Password: Last Name: First Name: Failure to do this will immediately render your email address deactivated from our database. Thank you,from the Support Team. ( We apologize for anyinconvenience this may cause) ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

[U-Boot] FYI
by Rhys Williams 30 Aug '11

30 Aug '11

FYI I have been waiting for you to pick up your Cashier Check of $800,000.00 USD EIGHT HUNDRED THOUSAND US DOLLARS before I leave the Federal Republic of Nigeria, but you did not show up as I did not hear from you. I am writing to inform you that I have deposited your cashier check with UNITED PARCEL SERVICE there in Nigeria.For your information, I'm now in Japan to resume my new job offer and will not go back to Nigeria till next year. Please you have to contact the United Parcel Service of Nigeria to know when they will deliver your package to your resident address in your country. Note that I have paid for the security keeping fee. The only money you will have to pay is the shipping/handling fee which only cost $80.00 US Dollars to receive your check parcel as agreed with them. Don't be deceived by any body because I have paid for the security keeping fee before they accepted the Cashier check. Please contact the company with their below details: Contact Person: David Churchill Tel:+234-818-627-9971 E-mail:david.churchill1@hotmail.co.uk Thanks for your attention. Regards, Rhys Williams

1 0

[U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
by Lukasz Majewski 30 Aug '11

30 Aug '11

MMC operations are performed on cache line size aligned buffers. In the current MMC implementation it is allowed to pass buffer with arbitrary alignment. In this patch assumption has been made, that it is better to align the buffer on the MMC framework boundary, than in a number of u-boot subsystems, which are using MMC. Signed-off-by: Lukasz Majewski <l.majewski(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> CC: Andy Fleming <afleming(a)gmail.com> CC: Albert ARIBAUD <albert.u.boot(a)aribaud.net> --- drivers/mmc/mmc.c | 30 +++++++++++++++++++++++++++--- 1 files changed, 27 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 5f79a17..47e94c8 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -263,6 +263,7 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t blkcnt, const void*src) struct mmc_cmd cmd; struct mmc_data data; int timeout = 1000; + void *cache_align_buf; if ((start + blkcnt) > mmc->block_dev.lba) { printf("MMC: block number 0x%lx exceeds max(0x%lx)\n", @@ -283,13 +284,22 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t blkcnt, const void*src) cmd.resp_type = MMC_RSP_R1; cmd.flags = 0; - data.src = src; + cache_align_buf = memalign(get_dcache_line_size(), + mmc->write_bl_len * blkcnt); + + if (!cache_align_buf) + return -ENOMEM; + + memcpy(cache_align_buf, src, mmc->write_bl_len * blkcnt); + + data.src = cache_align_buf; data.blocks = blkcnt; data.blocksize = mmc->write_bl_len; data.flags = MMC_DATA_WRITE; if (mmc_send_cmd(mmc, &cmd, &data)) { printf("mmc write failed\n"); + free(cache_align_buf); return 0; } @@ -303,6 +313,7 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t blkcnt, const void*src) cmd.flags = 0; if (mmc_send_cmd(mmc, &cmd, NULL)) { printf("mmc fail to send stop cmd\n"); + free(cache_align_buf); return 0; } @@ -310,6 +321,7 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t blkcnt, const void*src) mmc_send_status(mmc, timeout); } + free(cache_align_buf); return blkcnt; } @@ -342,6 +354,7 @@ int mmc_read_blocks(struct mmc *mmc, void *dst, ulong start, lbaint_t blkcnt) struct mmc_cmd cmd; struct mmc_data data; int timeout = 1000; + void *cache_align_buf; if (blkcnt > 1) cmd.cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK; @@ -356,13 +369,21 @@ int mmc_read_blocks(struct mmc *mmc, void *dst, ulong start, lbaint_t blkcnt) cmd.resp_type = MMC_RSP_R1; cmd.flags = 0; - data.dest = dst; + cache_align_buf = memalign(get_dcache_line_size(), + mmc->read_bl_len * blkcnt); + + if (!cache_align_buf) + return -ENOMEM; + + data.dest = cache_align_buf; data.blocks = blkcnt; data.blocksize = mmc->read_bl_len; data.flags = MMC_DATA_READ; - if (mmc_send_cmd(mmc, &cmd, &data)) + if (mmc_send_cmd(mmc, &cmd, &data)) { + free(cache_align_buf); return 0; + } if (blkcnt > 1) { cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION; @@ -371,6 +392,7 @@ int mmc_read_blocks(struct mmc *mmc, void *dst, ulong start, lbaint_t blkcnt) cmd.flags = 0; if (mmc_send_cmd(mmc, &cmd, NULL)) { printf("mmc fail to send stop cmd\n"); + free(cache_align_buf); return 0; } @@ -378,6 +400,8 @@ int mmc_read_blocks(struct mmc *mmc, void *dst, ulong start, lbaint_t blkcnt) mmc_send_status(mmc, timeout); } + memcpy(dst, cache_align_buf, mmc->read_bl_len * blkcnt); + free(cache_align_buf); return blkcnt; } -- 1.7.2.3

7 54

[U-Boot] RFC: Testing U-Boot Part 1
by Simon Glass 30 Aug '11

30 Aug '11

Hi, Summary: I am quite keen on improving the test infrastructure in U-Boot. I would like to have a test suite that can run in a minute or two on a Linux PC and test all non-platform code. Detail ====== We can break the U-Boot code base into two parts: 1. Platform code, which is SOC-specifc. At present this is the CPU init (arch/xxx/cpu/...) and SOC-specific drivers (mostly in the drivers directory). There is also a small amount of generic CPU code in arch/xxx/lib and some board-specific code/drivers (e.g. drivers not within the SOC). 2. Portable/Generic U-Boot code, which is cross-platform. This includes many drivers, the various commands, file system support, things like the MMC, USB and network stacks, etc. My focus in this email the the second part of the code base - all the code which is not platform-specific, but can still have bugs. Proposal ======== To a large extent, testing of this part of the code base could simply be built on one or more of the available platforms. We could then run the tests on that platform, and announce that the code base works fine on that platform. Obviously the platform needs to support all possible features of U-Boot. However, this approach fails to take advantage of two useful properties of this code: - It is cross-platform, and even runs on x86 - It is standalone, requiring no OS libraries to run For speed, debugging and convenience, it would be nice to run U-Boot under a generic Linux environment on a workstation, and test all the generic non-platform code. The basic problem with this is that the non-platform code requires the platform code to operate. Even the x86 platform code is designed for standalone operation on a particular x86 board, and is not suitable for running under x86 Linux. To get around this I propose that we create a new ‘native’ architecture. We write code in ‘arch/native’ which can run under Linux. Since all the non-platform code will happily run under this new ‘architecture’, we can then write tests which run quickly under x86 Linux (or another Linux for that matter). This U-Boot 'architecture' should build natively on any 32/64-bit Linux machine since it just uses standard Linux system calls. Calls to Linux would be entirely within this arch/native subdirectory. Benefit ======= What will this buy us? Well we can do things like: - Create a test SPI flash device, which is file-backed. Use this to write a test of the cmd_sf layer by issuing a series of commands and making sure that the correct SPI flash contents is obtained - Create a test MMC or IDE device, backed by a file. Use this to issue ext2 and fat commands to manipulate the filesystem. Then loopback mount the file and check from Linux that U-Boot did the right thing - Create a test Ethernet device with a mocked remote host attached. Use this to issue network commands like bootp and tftp and check that the correct results are obtained. Ultimately (one day) we might have a set of unit tests for U-Boot which can run to very quickly check that a patch does not break the core U-Boot code. Comments ======== At this early stage I am looking for comments on the concept - how useful it is and how best to implement it. Regards, Simon

7 18

[U-Boot] Device driver name - NET_MULTI
by Michal Simek 29 Aug '11

29 Aug '11

Hi, I have met with the problem where I setup longer network driver name than was allocated space in eth_device structure. That's why I think that registration code should check it. What do you think? Thanks, Michal

2 4

[U-Boot] Uboot 1.3.4 - splash screen problem
by Ramonf 29 Aug '11

29 Aug '11

Hi, I'm running uboot 1.3.4 on AT91SAM9M10EKES board. I'm trying to load BMP into it, but I get "There is no valid bmp file at the given address" when I'm running bmp info. what I do is this: $ tftp 10000 tftpboot/ramon.bmp $ bmp i 10000 I checked the BMP on my PC, and it's ok. what can be the problem ? -- View this message in context: http://old.nabble.com/Uboot-1.3.4---splash-screen-problem-tp32357132p323571… Sent from the Uboot - Users mailing list archive at Nabble.com.

2 1

[U-Boot] Fw: private message: open file plz.
by samuel gbagbo 29 Aug '11

29 Aug '11

1 0

[U-Boot] MIPS malta platform support in u-boot
by Abbas Raza 29 Aug '11

29 Aug '11

Hello, I want to use u-boot on MIPS malta platform. But as far as i know, u-boot has no support for MIPS malta platform. Is that right ? Can anyone guide me how to get support for this platform in u-boot , anyone has worked on it? will it require all work from scratch? Currently YAMON is available for this platform. Thanks ! Abbas Raza

1 0

[U-Boot] Problem with u-boot after stage 0
by Mirko Banchi 29 Aug '11

29 Aug '11

Hi all, we have developed a board very similar to MPC8306SOM board. We have some problems to run u-boot on. Briefly, the board has the same main components of the som board (RAM, NAND chip and a MPC8306 microprocessor) so we tried to use the same u-boot-nand.bin image for the boot. Something happens: the board starts, prints the message "NAND boot...transfering control" and nothing else happens. The first code is executed in NAND until nand_boot function (defined in the file nand_spl/nand_boot_fsl_elbc.c) is called: this copies in RAM the u-boot image and jumps at the address 0x01000000. To make we sure that RAM is working ok we have modified the u-boot-nand.bin with istructions that reset the processor and all works ok. Surely the jump at 0x01000000 happens and u-boot code starts to be executed but surely for some unknown reasons something goes wrong. Follow the u-boot code is very difficult also because is not clear to us how the "parts" of the boot loader are linked togheter. Now some questions: 1- Looking at the dump of u-boot-nand.bin we saw that there are two "parts" of code very similar: one starts at offset 0x0 and the other at offset 0x20000. Both parts begin with a reset configuration word followed by the u-boot magic number, string version etc... Which is the purpose of this two parts?This could be useful to better understand the boot process. For now we know only that the processor reads the configuration word in NAND at offset 0x0 and starts to execute istructions from offset 0x100 in NAND. The second "part" (that starts at offset 0x20000) is then copied in RAM and the code that is executed is at location 0x01000120 in RAM. 2 - In the function nand_boot defined in nand_spl/nand_boot_fsl_elbc.c the last istruction is the call to the function pointed by the function pointer uboot (its value is 0x01000120). Where can i find the code executed here? Which is the relative source file? Looking at that source file maybe i can find where the boot could stop. Thank you all very much! Best regards, Mirko -- Mirko Banchi e-mail: mk.banchi(a)gmail.com id-jabber: mk.banchi(a)jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456

1 0

[U-Boot] From the Google UK Office**** Confirm your E-mail usage immediately***
by Online Team® UK 29 Aug '11

29 Aug '11

We urgently wish to inform you again that your e-mail has w o n £850,000 UK Pounds {with L u c k y # :12-12-23-35-40-41(12) & T i c k e t # :008 695 757 336 64} in our on-going Google UK 12th Anniversary Online P r o m o. As indicated in your play coupon,Your w i n n i n g details falls under our ASIA Zone Disbursement booklet where your claim shall be processed. Kindly confirm if this email is "still in use" by sending your Name and Country to enable us provide you with full information. Email: thegoogleuk.giveawayteam(a)london.com For Inquiry : +44 7031 810 508 Congrats!!! Mr. Brian ®2011 Giveaway Online Announcer

1 0