Re: [U-Boot] Creating U-Boot env image
On: Tuesday, December 10, 2013 1:32 PM, Alexey Smishlayev wrote: > I'm not sure, if that's not something simple, that's why I wrote to this > list. I just don't know every little detail about using U-Boot. I was thinking something like: [flash-sector-size] <= [U-Boot-configured-env-size] and you must give the right number to the env image generation program. > That's what I've thought also - if I just dd the environment contents to > a file, can I then use it as a valid image for production? That could be > the most simple way to achieve what I want. Yes, should be possible. If you're using redundant environments, you probably want to use the env copy that has "0x01" in the 5:th byte. See common/env_flash.c and include/environment.h. // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Creating U-Boot env image
Hi Alexey, on: Monday, December 09, 2013 3:34 PM, Alexey Smishlayev wrote: > I would like to flash the environment variable values to my board, > rather than setting them at the prompt. I've founa a tool mkenvimage is > made specially for that. I used it to create a binary image of the > U-Boot environment. However, when I flash it to my board, I get the message > *** Warning - bad CRC, using default environment > > I thought it is due to that redundant memory wasn't written aswell, so I > commented out #define CONFIG_ENV_REDUND_OFFSET in the > include/configs/at91sam9g20ek.h, and tried once again, but I'm still > getting this error. I can definitely see the use case in producing a complete flash image, e.g. for production use and maybe be able to select the env image from one of many depending on some factor. What you describe should definitely be possible. Are you sure that it's not something simple like a missmatch in env size? You could use U-Boots Linux fw_printenv tools and/or dd to read the flashed env image and perhaps compare it to an image saved by U-Boot to figure out what is going wrong. BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPDX License IDs - moving forward
On Thursday, October 10, 2013 12:48 PM, Wolfgang Denk wrote: > This would allow to easily find out which components have actually > been built into the final product, so which licenses apply tho that. > You don't have to bother about license terms for code that you don't > actually use in your product, right? This sounds great to me! Much of the work I've done over the past months could have been done in a few days if all FOSS projects were using this approach. > Should we also add similar tags to list known patents etc.? Interesting! Would also help. BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP 4 Duovero change console UART port
Hi! Look in drivers/serial/serial_ns16550.c Changing ..COM3 to UART_BASE4 seems a bit unorthodox, Try changing to: #define CONFIG_SYS_NS16550_COM4 UART4_BASE << COM4!!! #define CONFIG_CONS_INDEX 4 BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Safe Linux Updater
Dear Wolfgang, I havn't seen the scripts of Alexandre but it sounds something like what we have already implemented. Wolfgang Denk wrote: > Please note that this is a feature standardized for example in the > Open Source Development Labs Carrier Grade Linux Requirements > Definition, which says something like: "CGL shall provide support > for detecting a repeating reboot cycle due to recurring failures > and will go to an offline state if this occurs." As I read Alexandre, the aim is to revert to a previous functional image, not to go to an offline state. > Normally you want to avoid all erase / write operations to > the boot loader and it's private data structures in the process of > a normal reboot / reset. But a failing boot is not a normal boot. This should only occur when an update fails. After a maximum number of failing boots, the old functional image is used and there is no need to update the counter any more. Best Regards, Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored
Hi Michael, Michael Heimpold [m...@heimpold.de] wrote: > fw_setenv state=2 > dd if=... of=/dev/mmcblk0... > fw_setenv state=1 How about: fw_setenv state 1 && sync BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fatwrite problem
Hi Ruud,
Ruud Commandeur wrote:
> Once the size of the set_cluster call equals 0, the mmc command is
> incomplete and times out. In the earlier reported problem, a patch is
> mentioned, but not available for dowload here. Also in the latest
> versions of the git repository I could not find a patch for this
> problem. Can anyone tell me if there is a fix for this problem?
I asked Damien Huang (back then) and got the following reply (I think there was
some character encoding problem so his mail never was accepted by the list).
I have not further analyzed the contents, anyway it wasn't the solution to my
problem.
BR // Mats
Damien Huang wrote:
As requested from Mats, I am resending this email. The patch is given below:
diff -cr ./u-boot-original/u-boot/fs/fat/fat_write.c
./u-boot-test/u-boot/fs/fat/fat_write.c
*** ./u-boot-original/u-boot/fs/fat/fat_write.c2013-02-07
14:47:33.314732999 +1100
--- ./u-boot-test/u-boot/fs/fat/fat_write.c2013-02-28 15:36:24.551861920
+1100
***
*** 562,596
{
int idx = 0;
__u32 startsect;
!
! if (clustnum > 0)
! startsect = mydata->data_begin +
! clustnum * mydata->clust_size;
! else
! startsect = mydata->rootdir_sect;
!
! debug("clustnum: %d, startsect: %d\n", clustnum, startsect);
!
! if (disk_write(startsect, size / mydata->sect_size, buffer) < 0) {
! debug("Error writing data\n");
! return -1;
! }
!
! if (size % mydata->sect_size) {
! __u8 tmpbuf[mydata->sect_size];
!
! idx = size / mydata->sect_size;
! buffer += idx * mydata->sect_size;
! memcpy(tmpbuf, buffer, size % mydata->sect_size);
!
! if (disk_write(startsect + idx, 1, tmpbuf) < 0) {
! debug("Error writing data\n");
! return -1;
! }
!
! return 0;
! }
!
return 0;
}
--- 562,595
{
int idx = 0;
__u32 startsect;
! if(size) //if there are data to be set
! {
! if (clustnum > 0)
! startsect = mydata->data_begin +
! clustnum * mydata->clust_size;
! else
! startsect = mydata->rootdir_sect;
!
! debug("clustnum: %d, startsect: %d\n", clustnum, startsect);
!
! if (disk_write(startsect, size / mydata->sect_size, buffer) < 0) {
! debug("Error writing data\n");
! return -1;
! }
!
! if (size % mydata->sect_size) {
! __u8 tmpbuf[mydata->sect_size];
!
! idx = size / mydata->sect_size;
! buffer += idx * mydata->sect_size;
! memcpy(tmpbuf, buffer, size % mydata->sect_size);
!
! if (disk_write(startsect + idx, 1, tmpbuf) < 0) {
! debug("Error writing data\n");
! return -1;
! }
! }
! }//end if data to be set
return 0;
}
diff -cr ./u-boot-original/u-boot/include/configs/am335x_evm.h
./u-boot-test/u-boot/include/configs/am335x_evm.h
*** ./u-boot-original/u-boot/include/configs/am335x_evm.h2013-02-07
14:47:35.754702325 +1100
--- ./u-boot-test/u-boot/include/configs/am335x_evm.h2013-03-01
12:25:23.942104474 +1100
***
*** 143,148
--- 143,149
#define CONFIG_CMD_MMC
#define CONFIG_DOS_PARTITION
#define CONFIG_FS_FAT
+ #define CONFIG_FAT_WRITE
#define CONFIG_FS_EXT4
#define CONFIG_CMD_FAT
#define CONFIG_CMD_EXT2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2013.04-rc2 released
Hi Tom, Tom Rini wrote: > If you have specific bugfixes, please hit me up and CC the list. [U-Boot] powerpc/lib: fix unsafe register handling in wait_ticks (2012-01-27) Out of curiosity and perhaps to have better success in the future; what is the reason that this patch hasn't made it into the release? BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problems around fatwrite command from uboot
> 2013/2/28 Damien HUANG > > After investigation, I believe the problem can be fixed at function > "set_cluster" within file fat_write.c under directory /fs/fat (patch file > was attached). > Hi Damien, I found no trace of your patch in the mailing list (perhaps the attachment was dropped by the list server or there was some other encoding error). It may be interesting for others (like me ;) to see what you have done so could you re-post it to the list as plain text in the mail? BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problems around fatwrite command from uboot
Jean Louis wrote:
> Many thanks for your great help, I change the code as you say by :
>
> ~line 659:
> if ((fat_val == 0xfff && mydata->fatsize == 32) ||
> (fat_val == 0x && mydata->fatsize == 16))
> break;
> ~line 904:
> if ((curclust >= 0xff8 && mydata->fatsize == 32) ||
> (curclust >= 0xfff8 && mydata->fatsize == 16)) {
> empty_dentptr = dentptr;
> return NULL;
> }
>
> I will do more tests with these changes.
Yes, that's what I had in mind. However there is also FAT12 but I think that is
only
used for floppy disks and nobody uses those anymore ?!?
Please post your test results to the list!
> Thank you
You're welcome ;)
Btw. I have also seen the missalignment warnings that Tom Rini just posted
about but
I don't know if it's just performance that suffers or if the missalignment may
also cause
corruption. Tom?
// Mats
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problems around fatwrite command from uboot
Hi Jean,
Accidentally I'm also currently debugging fat_write.
I have a problem with USB EHCI time-outs while writing but so far I have not
found a cure.
What I have found is this rather strange code in fat_write.c:
~line 659:
if (fat_val == 0xfff || fat_val == 0x)
break;
~line 904:
if ((curclust >= 0xff8) || (curclust >= 0xfff8)) {
empty_dentptr = dentptr;
return NULL;
}
Both these conditions seem to be plain wrong. They should probably take
mydata->fatsize into account and select either of the conditions. I suspect
that they could cause errors in the FAT chains by triggering on the FAT16
condition when actually running on FAT32.
Good luck!
BR // Mats
From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on behalf of
Jean Louis [1978...@gmail.com]
Sent: Thursday, February 21, 2013 12:33 PM
To: u-boot@lists.denx.de
Subject: [U-Boot] Problems around fatwrite command from uboot
Hi,
I use the last uboot from your git and boot with it on AM3517 EVM from SD
card
without NAND.
I use this option in uboot config : #define CONFIG_FAT_WRITE 1
I use intensively fatload / fatwrite commands at the boot before kernel
loading.
Sometimes, in about 2% of cases of boot, the FAT becomes inconsistent and I
have
systematically these messages at boot when I use fatwrite command :
U-Boot 2013.01-gd3b9a66-dirty (Feb 21 2013 - 11:02:33)
...
writing MODIFYME.001
mmc_send_cmd: timedout waiting on cmd inhibit to clear
mmc_send_cmd: timedout waiting on cmd inhibit to clear
mmc_send_cmd: timedout waiting on cmd inhibit to clear
mmc_send_cmd: timedout waiting on cmd inhibit to clear
mmc_send_cmd: timedout waiting on cmd inhibit to clear
mmc_send_cmd: timedout waiting on cmd inhibit to clear
mmc_send_cmd: timedout waiting on cmd inhibit to clear
mmc_send_cmd: timedout waiting on cmd inhibit to clear
mmc_send_cmd: timedout waiting on cmd inhibit to clear
mmc_send_cmd: timedout waiting on cmd inhibit to clear
mmc_send_cmd: timedout waiting on cmd inhibit to clear
42428 bytes written
...
unlike that is said at the last line, the file is not written.
If I run a 'fatls' command before this fatwrite, I see the same file
'modifyme.001' twice :
AM3517_EVM # fatls mmc 0:1
42428 mlo
261332 u-boot.bin
2 modifyme.001
2 modifyme.001
2644996 uimage
...
After the board boot on linux, I run this command to repair FAT part:
umount /dev/mmcblk0p1 ; fsck.vfat -a -w -v /dev/mmcblk0p1
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
4096 bytes per cluster
34 reserved sectors
First FAT starts at byte 17408 (sector 34)
2 FATs, 32 bit entries
321024 bytes per FAT (= 627 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 659456 (sector 1288)
80156 data clusters (328318976 bytes)
63 sectors/track, 255 heads
63 hidden sectors
642537 sectors total
Wrong checksum for long file name "modifyme.001".
(Short name MODIFYME.001 may have changed without updating the long name)
Not auto-correcting this.
/modifyme.001
Contains a free cluster (3081). Assuming EOF.
/modifyme.001
File size is 2 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.
Reclaiming unconnected clusters.
Checking free cluster summary.
Performing changes.
/dev/mmcblk0p1: 24 files, 3487/80156 clusters
As you can see in this return, the error 'Wrong checksum for long file name
"modifyme.001"' often appears after use of fatwrite command at the boot.
After the part is repaired, I reboot the board and uboot run as infinite
loop
after the fatwrite command :
writing MODIFYME.001
error: overflow occurs
error: overflow occurs
error: overflow occurs
error: overflow occurs
error: overflow occurs
...
( seems to be error in source code at disk_write() /* Write FAT buf
*/ in flush_fat_buffer() )
I do an electrical off / on of my board during this infinite loop and the
next
boot seems okay but the file is once again corrupted, we can see that the
count
is incorrect (4096 and not 42428) :
...
42428 bytes read in 6 ms (6.7 MiB/s)
writing MODIFYME.001
4096 bytes written
...
A fatload at the next boot says 'Invalid FAT Entry' :
...
reading MODIFYME.001
Invalid FAT entry
...
If I try to fatwrite an another file in this situation, I fall in the first
case
( mmc_send_cmd: timedout waiting on cmd inhibit to clear )
I think that the fatwrite command is potentially incomplete maybe around :
- free cluster summary
- second FAT entry
- short/long filenames
- deleted files entries
any help appreciated
Best regards,
Jean Louis.
(France)
___
U-Bo
Re: [U-Boot] common/cmd_disk.c doesn't actually define any "commands"
Hi Albert, Albert ARIBAUD wrote: > Maybe, but the problem you state is not about cmd_disk (or I am > missing the point). USB commands are in USB related files, e.g. > do_usbboot() is in cmd_usb.c, so that's where a conditional should be > put if you want to compile the command out, rather than in cmd_disk, > which does not add to the U-Boot commands table at all. The cmd_usb file contains all the other USB commands through "do_usb" and "usbboot" through "do_usbboot" that is just a forward to "common_diskboot". Maybe the major miss-feature here is that you get usbboot and a bunch of extra code, just because you want to be able to read USB memories. This could of course be fixed by revising the ifdefs in cmd_usb etc. instead but in that case I support Robert in his remark about the file naming ;) BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] common/cmd_disk.c doesn't actually define any "commands"
Hi Robert, Albert, > Robert P. J. Day wrote: > just to be clear, i have no strong opinion on this either way, but > my understanding is that source files with the name of "common/cmd_*.c" > typically define at least one u-boot "command" with the U_BOOT_CMD macro. > as far as i can tell, cmd_disk.c is the only counterexample of that. I was just looking into this myself but from another perspective. I'm using "CONFIG_USB:STORAGE" and because of the way things are made, I then automatically get "usbboot" for which I have no use. Things would be more logical if it was up to cmd_disk to define the commands based on ifdef's for the various backends -- but ONLY if CONFIG_CMD_DISK was in the config file. Maybe this upsets a lot of other people though...? Best regards, Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] vfat: Fix mkcksum argument sizes
Marek Vasut denx.de> wrote: > In case a function argument is known/fixed size array in C, the argument is > still decoyed as pointer instead ( T f(U n[k]) ~= T fn(U *n) ) and therefore > calling sizeof on the function argument will result in the size of the > pointer, > not the size of the array. > > The VFAT code contains such a bug, this patch fixes it. > I had the same problem with VFAT formatted USB stick on U-Boot 2013.01 as the original bug reported by Michail Simek. I have not made any deeper analysis of your patch, but it solved the problem. Thanks! BR / Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/lib: fix unsafe register handling in wait_ticks
If watchdog is enabled, the arch/powerpc/lib/ticks.S::wait_ticks() function calls the function specified by the WATCHDOG_RESET macro. The wait_ticks function depends on the registers r0, r6 and r7 being preserved however that is not guaranteed, e.g. if the reset function is a C function this will probably overwrite r0 and cause an endless loop. The following patch changes to using r14+r15 instead of r6+r7 (to resemble what would have been generated by a C compiler) and saves all necessary registers on the stack. The patch has been tested on a custom MPC5125 based machine using the 512x powerpc architecture. Signed-off-by: Mats Karrman Cc: Wolfgang Denk Acked-by: Joakim Tjernlund --- arch/powerpc/lib/ticks.S | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/lib/ticks.S b/arch/powerpc/lib/ticks.S index 1781039..63114bb 100644 --- a/arch/powerpc/lib/ticks.S +++ b/arch/powerpc/lib/ticks.S @@ -50,19 +50,24 @@ wait_ticks: stwur1, -16(r1) mflrr0 /* save link register */ stw r0, 20(r1) /* Use r0 or GDB will be unhappy */ - mr r7, r3 /* save tick count */ + stw r14, 12(r1) /* save used registers */ + stw r15, 8(r1) + mr r14, r3 /* save tick count */ bl get_ticks /* Get start time */ /* Calculate end time */ - addcr7, r4, r7 /* Compute end time lower */ - addze r6, r3 /* and end time upper */ + addcr14, r4, r14/* Compute end time lower */ + addze r15, r3 /* and end time upper */ WATCHDOG_RESET /* Trigger watchdog, if needed */ 1: bl get_ticks /* Get current time */ - subfc r4, r4, r7 /* Subtract current time from end time */ - subfe. r3, r3, r6 + subfc r4, r4, r14 /* Subtract current time from end time */ + subfe. r3, r3, r15 bge 1b /* Loop until time expired */ - mtlrr0 /* restore link register */ + lwz r15, 8(r1) /* restore saved registers */ + lwz r14, 12(r1) + lwz r0, 20(r1) addir1,r1,16 + mtlrr0 blr -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] powerpc/lib: unsafe register handling in wait_ticks
Hi, If watchdog is enabled, the arch/powerpc/lib/ticks.S::wait_ticks() function calls the function specified by the WATCHDOG_RESET macro. The wait_ticks function depends on the registers r0, r6 and r7 being preserved however that is not guaranteed if the reset function is a C function. The following patch changes to using r14+r15 instead of r6+r7 and saves all necessary registers on the stack. As I'm quite fresh to PowerPC assembly language I would appreciate any feedback on the implementation. On a side note, one could wonder why this function is not written in C language to start with. Best regards, Mats Kärrman --- a/arch/powerpc/lib/ticks.S +++ b/arch/powerpc/lib/ticks.S @@ -50,19 +50,24 @@ wait_ticks: stwur1, -16(r1) mflrr0 /* save link register */ stw r0, 20(r1) /* Use r0 or GDB will be unhappy */ - mr r7, r3 /* save tick count */ + stw r14, 12(r1) /* save used registers */ + stw r15, 8(r1) + mr r14, r3 /* save tick count */ bl get_ticks /* Get start time */ /* Calculate end time */ - addcr7, r4, r7 /* Compute end time lower */ - addze r6, r3 /* and end time upper */ + addcr14, r4, r14/* Compute end time lower */ + addze r15, r3 /* and end time upper */ WATCHDOG_RESET /* Trigger watchdog, if needed */ 1: bl get_ticks /* Get current time */ - subfc r4, r4, r7 /* Subtract current time from end time */ - subfe. r3, r3, r6 + subfc r4, r4, r14 /* Subtract current time from end time */ + subfe. r3, r3, r15 bge 1b /* Loop until time expired */ - mtlrr0 /* restore link register */ + lwz r15, 8(r1) /* restore saved registers */ + lwz r14, 12(r1) + lwz r0, 20(r1) addir1,r1,16 + mtlrr0 blr ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:21: > Looking at the watchdog impl. I see it can be normal C code. This makes > wait_ticks unsafe > (even before my patch) as wait_ticks relies on r6 and r7 (and with my > patch r0 too) > to be unmodified. Yes! I can see in the assembly from my watchdog_reset() (arch/powerpc/cpu/mpc5125/cpu.c) that it does not touch r7 and r8 but indeed r0 -- for storing lr in fact so the endless loop is explained! Many thanks! I'll prepare a patch as soon as I've got one tested. BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:58:35: > > > > > > Me neither, there is not a lot details. I do recall having other > problems with > > > wait_ticks from time to time, sometimes the TB counter(mtfbu, mftb in > get_ticks) > > > would not increment so one would just loop forever in wait_ticks. This > problem > > > had nothing to do with my patch though. > > > Never got around to finding out what caused it, we ended up blaming > unstable HW. > > > > > > Some ideas though: > > > - Perhaps you have some alignment problem, try adding nop's here and > there. > > > - My patch uses r0(which is what one should use to make gdb happy) > instead of r8 > > > to stash the LR. Possibly you have some odd dependency on r0, try > using r8 again. > > > > Try getting LR from stack instead of trusting r0 to be valid: > > - mtlrr0 /* restore link register */ > > + lwz r0, 20(r1) /* restore link register */ > > + mtlrr0 > > This is what one should do but as we have complete control of r0 here we > don't need to. > > > > hmm, do you have WATCHDOG_RESET defined? does it use r0? > > I guess the above patch would make wait_ticks safer from accidental use > by > > WATCHDOG_RESET, > > if it works for you, please send a proper patch to u-boot. > > Looking at the watchdog impl. I see it can be normal C code. This makes > wait_ticks unsafe > (even before my patch) as wait_ticks relies on r6 and r7 (and with my > patch r0 too) > to be unmodified. > > This MIGHT be the fix: > --- a/arch/powerpc/lib/ticks.S > +++ b/arch/powerpc/lib/ticks.S > @@ -56,13 +56,17 @@ wait_ticks: > /* Calculate end time */ > addcr7, r4, r7 /* Compute end time lower */ > addze r6, r3 /* and end time upper */ > - > + stw r7, 4(r1) /* Stash r6 and r7 */ > + stw r6, 8(r1) > WATCHDOG_RESET /* Trigger watchdog, if needed */ > + lwz r7, 4(r1) > + lwz r6, 8(r1) > 1: bl get_ticks /* Get current time */ > subfc r4, r4, r7 /* Subtract current time from end time */ > subfe. r3, r3, r6 > bge 1b /* Loop until time expired */ > > - mtlrr0 /* restore link register */ > + lwz r0, 20(r1) /* restore link register */ > + mtlrr0 > addir1,r1,16 > blr > > Not sure about the 4 and 8 offsets though > > Jocke Thanks for feedback! I will look into this ASAP (maybe not until tomorrow). I'll report back as soon as I have a result. BR, Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
Dear Wolfgang Denk, >> Found that it was looping endlessly in >> arch/powerpc/lib/ticks.S::wait_ticks(). Reverting commit "ppc: Create a >> stack frame for wait_ticks()" made everything work again. > > This makes no sense to me - especially as it works on all other > systems. If you say it works, it makes no sense to me either. I thought it might be some subtle difference in the way the e300c4 core or GCC works compared to other PPC cores. If there are no such differences, then a patch with no intended functional difference beyond keeping gdb happy should not make any difference, good or bad. > Well, you mentioned you were using a MPC5125 processor which is not > supported in mainline U-Boot, and which is known to have enough > differences in it's register layout that anything might be the cause > for such issues. > > Is it correct to assume that you have a _lot_ of local modifiucations > in your tree? I bet the problem lies there... I wouldn't say a lot. I'm using only the serial console to be able to download and flash images (using CFI flash) and to boot Linux so the primary patches are the serial driver and the DRAM initialization. On top of that there are some minimal I/O initialization and of course I went through and updated the register mappings for the relevant peripherals. It worked fine with 2009.03 and with 2012.07 but of course I might have overlooked something. I will report back when / if I find out something more. I'm not much for betting though ;) Best regards, Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
> Now when I'm trying to migrate to U-Boot 2013.01 I face problems with a > sudden hang. I see console output until the "Flash:" from > arch/powerpc/lib/board.c::board_init_r() but nothing more until the board > reboots on a watchdog reset after 30s. Found that it was looping endlessly in arch/powerpc/lib/ticks.S::wait_ticks(). Reverting commit "ppc: Create a stack frame for wait_ticks()" made everything work again. I am not fluent enough in powerpc assembly or gcc stack frames for the same to see exactly what is wrong. Perhaps someone with the necessary mileage could take a look? BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
Hi! I have a system using a MPC5125 processor working fine using U-Boot 2012.07. I have based my board adaption etc on the mpc5121ads board and also patched the necessary parts of the serial port driver. Now when I'm trying to migrate to U-Boot 2013.01 I face problems with a sudden hang. I see console output until the "Flash:" from arch/powerpc/lib/board.c::board_init_r() but nothing more until the board reboots on a watchdog reset after 30s. I have looked for relevant changes in the U-Boot code and tried some printf debugging. So far I have been unable to pin down exactly where things go wrong. Question: To help me decide where to look I would like to know if anyone has built the mpc5121ads board configuration using U-Boot 2013.01 and actually tested that it is still working? Thanks & best regards, Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] hashtable lib and escaping
Hi, > Any chance that you are not using the hush shell, but the old, simple > command interpreter? Yup, a 100% chance. As I wrote before I rely only on the default environment, apart from development work, so I removed everything I don't need, hush included. With some luck I will have time to look more at this later on. Best regards, Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] hashtable lib and escaping
Thanks for your advice. I did not say so, but I'm primarily relying on the default environment and not so much the command line. I see now how to make this work by providing the necessary amount of backslash'es. Maybe it was your statement: > THis syntax has never been correct. If it ever worked, than only by > chance (read: because of incorrect/imperfect code). that set me off wrong, because in 2009.03 (before the introduction of hashtable) it did work and there were no confusing parsing of escapes. Still the parsing I see now is not exactly user friendly, example (U-Boot 2012.07): => setenv foo echo part one\\\;echo part two => print foo foo=echo part one\\;echo part two => run foo part one\;echo part two => printenv foo foo=echo part one\\;echo part two => printenv foo=echo part one;echo part two here the run and print commands yields the expected result based on the setenv but not "printenv" alone, and my results does not match your example which were >=> setenv foo echo part one\\\;echo part two ; print foo ; run foo >foo=echo part one\;echo part two >part one;echo part two Best Regards, Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] hashtable lib and escaping
Thanks, but... If not correct, then what is this supposed to mean (common/main.c :: builtin_run_command()): /* * Find separator, or string end * Allow simple escape of ';' by writing "\;" */ This does not indicate "by chance", or was it something else that was not correct? BR // Mats > From: Wolfgang Denk [w...@denx.de] > Sent: Thursday, November 01, 2012 9:00 PM > To: Mats Kärrman > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] hashtable lib and escaping > > Dear Mats Kärrman, > > In message you > wrote: > > > > I used to have a working setup using U-Boot 2009.03 before upgrading to > > U-Boot 2012.07. The problem I'm facing is related to the escaping policies > > of lib/hashtable.c. > > > > What I did before was for example having something like this in my default > > environment: > > > > bootcmd=run first_boot > > first_boot=setenv bootcmd my_select\;run ubi_boot;saveenv;boot > > THis syntax has never been correct. If it ever worked, than only by > chance (read: because of incorrect/imperfect code). > > > With the escape parsing of himport_r(), the '\' is simply dropped and it is > > no longer possible to escape ';' so the "run ubi_boot" is immediately > > executed and nothing is saved... The function header mentions the > > possibility for multi-line values but thi > > s should not come at the cost of not being able to escape ';'. > > You have to be casreful here and keep in mind that (de-) escaping will > take place in a different places: himport() (resp. setenv()) is only > one part of this story - the other part is when you will actually pass > this string to the command processor (the shell). > > See here: > > => setenv foo 'echo part one\;echo part two' ; print foo ; run foo > foo=echo part one;echo part two > part one > part two > => setenv foo 'echo part one\\;echo part two' ; print foo ; run foo > foo=echo part one\;echo part two > part one;echo part two > => > > > > 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 > "No matter where you go, there you are..." - Buckaroo Banzai > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] hashtable lib and escaping
Hi, I used to have a working setup using U-Boot 2009.03 before upgrading to U-Boot 2012.07. The problem I'm facing is related to the escaping policies of lib/hashtable.c. What I did before was for example having something like this in my default environment: bootcmd=run first_boot first_boot=setenv bootcmd my_select\;run ubi_boot;saveenv;boot The trick accomplished was that the environment was saved after setting the real bootcmd (to "my_select;run ubi_boot") on first boot so that the booted OS could always be relying on a valid environment in one of the flash env partitions. With the escape parsing of himport_r(), the '\' is simply dropped and it is no longer possible to escape ';' so the "run ubi_boot" is immediately executed and nothing is saved... The function header mentions the possibility for multi-line values but this should not come at the cost of not being able to escape ';'. I am not sure about what other uses the escape may have or used to have so I have not come up with a patch yet. Does anyone have any feedback/opinions concerning this? BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
