[U-Boot-Users] Command history no longer working
Hi, I have observed that after this commit, the command history is no longer working:
--- commit 597f6c26a18b389903a64692bacbf9a1ca69355b Author: James Yang James.Yang@freescale.com Date: Mon May 5 10:22:53 2008 -0500
Fix readline_into_buffer() with CONFIG_CMDLINE_EDITING before relocating
When CONFIG_CMDLINE_EDITING is enabled, readline_into_buffer() doesn't work before relocating to RAM because command history is written into a global array that is not writable before relocation. This patch defers to the no-editing and no-history code in readline_into_buffer() if it is called before relocation. ---
Based on the comments, I dont understand why it ceases to work because, in my case, U-Boot runs entirely from RAM (it is copied from flash to RAM by a first stage bootloader).
I have CONFIG_CMDLINE_EDITING defined.
Hugo V.
Hugo Villeneuve Hardware developer | Concepteur matériel Lyrtech Phone/Tél. : (1) (418) 877-4644 #2395 Toll-free/Sans frais — Canada & USA : (1) (888) 922-4644 #2395 Fax/Téléc. : (1) (418) 877-7710 www.lyrtech.com Infinite possibilities…TM
u-boot-users-bounces@lists.sourceforge.net wrote:
Hi, I have observed that after this commit, the command history is no longer working:
commit 597f6c26a18b389903a64692bacbf9a1ca69355b Author: James Yang James.Yang@freescale.com Date: Mon May 5 10:22:53 2008 -0500
Fix readline_into_buffer() with CONFIG_CMDLINE_EDITING beforerelocating
When CONFIG_CMDLINE_EDITING is enabled, readline_into_buffer()doesn't work before relocating to RAM because command history is written into a global array that is not writable before relocation. This patch defers to the no-editing and no-history code in readline_into_buffer() if it is called before relocation.
Based on the comments, I dont understand why it ceases to work because, in my case, U-Boot runs entirely from RAM (it is copied from flash to RAM by a first stage bootloader).
I have CONFIG_CMDLINE_EDITING defined.
Well after reading through the code in common/main.c, I figured that by setting GD_FLG_RELOC in my board init function:
gd->flags |= GD_FLG_RELOC;
command history would be working again, and it did.
But is it the right thing to do?
I noticed that not a lot of platforms/boards set GD_FLG_RELOC so command history will probably cease to work for these boards also?
Hugo V.
Hugo Villeneuve Hardware developer | Concepteur matériel Lyrtech Phone/Tél. : (1) (418) 877-4644 #2395 Toll-free/Sans frais — Canada & USA : (1) (888) 922-4644 #2395 Fax/Téléc. : (1) (418) 877-7710 www.lyrtech.com Infinite possibilities…TM
On Thu, 2008-05-29 at 15:41 -0400, Hugo Villeneuve wrote:
u-boot-users-bounces@lists.sourceforge.net wrote:
Hi, I have observed that after this commit, the command history is no longer working:
commit 597f6c26a18b389903a64692bacbf9a1ca69355b Author: James Yang James.Yang@freescale.com Date: Mon May 5 10:22:53 2008 -0500
Fix readline_into_buffer() with CONFIG_CMDLINE_EDITING beforerelocating
When CONFIG_CMDLINE_EDITING is enabled, readline_into_buffer()doesn't work before relocating to RAM because command history is written into a global array that is not writable before relocation. This patch defers to the no-editing and no-history code in readline_into_buffer() if it is called before relocation.
Based on the comments, I dont understand why it ceases to work because, in my case, U-Boot runs entirely from RAM (it is copied from flash to RAM by a first stage bootloader).
I have CONFIG_CMDLINE_EDITING defined.
Well after reading through the code in common/main.c, I figured that by setting GD_FLG_RELOC in my board init function:
gd->flags |= GD_FLG_RELOC;
command history would be working again, and it did.
But is it the right thing to do?
Yes.
I noticed that not a lot of platforms/boards set GD_FLG_RELOC so command history will probably cease to work for these boards also?
Most boards do the relocation and then it gets set by the common board_init_r() function.
Kenneth Johansson wrote:
On Thu, 2008-05-29 at 15:41 -0400, Hugo Villeneuve wrote:
u-boot-users-bounces@lists.sourceforge.net wrote:
Hi, I have observed that after this commit, the command history is no longer working:
commit 597f6c26a18b389903a64692bacbf9a1ca69355b Author: James Yang James.Yang@freescale.com Date: Mon May 5 10:22:53 2008 -0500
Fix readline_into_buffer() with CONFIG_CMDLINE_EDITING beforerelocating
When CONFIG_CMDLINE_EDITING is enabled, readline_into_buffer() doesn't work before relocating to RAM because command history is written into a global array that is not writable before relocation. This patch defers to the no-editing and no-history code in readline_into_buffer() if it is called beforerelocation. ---
Based on the comments, I dont understand why it ceases to work because, in my case, U-Boot runs entirely from RAM (it is copied from flash to RAM by a first stage bootloader).
I have CONFIG_CMDLINE_EDITING defined.
Well after reading through the code in common/main.c, I figured that by setting GD_FLG_RELOC in my board init function:
gd->flags |= GD_FLG_RELOC;
command history would be working again, and it did.
But is it the right thing to do?
Yes.
I noticed that not a lot of platforms/boards set GD_FLG_RELOC so command history will probably cease to work for these boards also?
Most boards do the relocation and then it gets set by the common board_init_r() function.
All right then, my board is based ont he ARM926, so I have added the code to my misc_init_r() function.
While looking into this problem, I think I have found a small glitch with the original patch for the commit 597f6c26a18b389903a64692bacbf9a1ca69355b. I´m sending a patch in a few minutes to try to correct it.
Hugo V.
Hugo Villeneuve Hardware developer | Concepteur matériel Lyrtech Phone/Tél. : (1) (418) 877-4644 #2395 Toll-free/Sans frais - Canada & USA : (1) (888) 922-4644 #2395 Fax/Téléc. : (1) (418) 877-7710 www.lyrtech.com Infinite possibilities...TM
Hi
On Thu, May 29, 2008 at 9:58 PM, Kenneth Johansson kenneth@southpole.se wrote:
I noticed that not a lot of platforms/boards set GD_FLG_RELOC so command history will probably cease to work for these boards also?
Most boards do the relocation and then it gets set by the common board_init_r() function.
I got hit by this problem today and only after I figured out what was really wrong I searched the mailing list archives and found this thread (and a couple of others).
I'm using an ARM board and as far as I can see lib_arm/board.c does not set the GD_FLG_RELOC bit, in fact no ARM boards do so in the current git tree (according to grep anyway). Many other architectures set the flag in their respective common lib_<arch>/board.c. Should/can the GD_FLG_RELOC be set in a common place (lib_arm/board.c:start_armboot) for ARM as well?
Or shall we place gd->flags |= GD_FLG_RELOC in the board specific init routines/files?
Regards, Magnus Lilja
participants (3)
-
Hugo Villeneuve -
Kenneth Johansson -
Magnus Lilja