[U-Boot-Users] Best place to implement custom "bootdelay" functionnality

Hi everybody,
I've ported U-Boot to a custom board without major problems, and I'm currently adding the few features I still miss.
Our board has a reset switch which can be held in the reset position to stop the automatic boot procedure. When the button is pushed to the reset position, a short reset pulse is generated by a CPLD to reset the CPU and run U-Boot. I then would like to check if the button is held in the reset position (which can easily be done by reading the CPLD status byte) and blink a LED until the button is released. The number of times the LED blinks before the user releases the reset button determines the boot options.
If the button has been held long enough, I would like to stop the U-Boot automatic boot process, much like a character on the serial port does.
I thought I would implement the button check and LED blink code in last_stage_init(void). I'd like to get advices regarding the best way to then tell U-Boot not to run bootcmd automatically.
On a side note, I have to program a Xilinx FPGA to make the LED blink (I know, this could have been put into the CPLD, that's probably a small design mistake). fpga_load() can easily be called from last_stage_init(), but I wonder if there is a public API to load the FPGA configuration file from a CramFS partition much like the fsload command does. I'd like to avoid duplicate code as much as possible.
Thanks in advance for your help.
Laurent Pinchart

In message 200607171733.37832.laurent.pinchart@tbox.biz you wrote:
If the button has been held long enough, I would like to stop the U-Boot automatic boot process, much like a character on the serial port does.
See the other boards which modify boot behavious depeinding on key presses at power-on / reset (like lwmon, trab, delta, ...).
I thought I would implement the button check and LED blink code in last_stage_init(void). I'd like to get advices regarding the best way to then tell U-Boot not to run bootcmd automatically.
The boards we ported usually execute programmable commands when a key press (resp. a combination of keys) is detected. Such a command can for example modify the bootdelay setting, change bootargs or redefine bootcmd.
mistake). fpga_load() can easily be called from last_stage_init(), but I wonder if there is a public API to load the FPGA configuration file from a CramFS partition much like the fsload command does. I'd like to avoid duplicate code as much as possible.
Yes, there is. Guess what common/cmd_fpga.c and common/fpga.c are for...
Best regards,
Wolfgang Denk

Hi Wolfgang,
On Monday 17 July 2006 20:41, Wolfgang Denk wrote:
In message 200607171733.37832.laurent.pinchart@tbox.biz you wrote:
If the button has been held long enough, I would like to stop the U-Boot automatic boot process, much like a character on the serial port does.
See the other boards which modify boot behavious depeinding on key presses at power-on / reset (like lwmon, trab, delta, ...).
I thought I would implement the button check and LED blink code in last_stage_init(void). I'd like to get advices regarding the best way to then tell U-Boot not to run bootcmd automatically.
The boards we ported usually execute programmable commands when a key press (resp. a combination of keys) is detected. Such a command can for example modify the bootdelay setting, change bootargs or redefine bootcmd.
Redefining bootcmd is probably the easiest way to go, I haven't thought about it. Thanks a lot for the advice.
mistake). fpga_load() can easily be called from last_stage_init(), but I wonder if there is a public API to load the FPGA configuration file from a CramFS partition much like the fsload command does. I'd like to avoid duplicate code as much as possible.
Yes, there is. Guess what common/cmd_fpga.c and common/fpga.c are for...
common/cmd_fpga.c and common/fpga.c are used to configure the FPGA from an in-memory configuration bitstream. What I'm looking for is a function to load the bitstream from a CramFS partition to memory, much like the fsload command does. Something similar to fpga_load() would be useful, some kind of fs_load(buffer, length, partition, filename).
Best regards,
Laurent Pinchart

In message 200607181054.37865.laurent.pinchart@tbox.biz you wrote:
common/cmd_fpga.c and common/fpga.c are used to configure the FPGA from an in-memory configuration bitstream. What I'm looking for is a function to load the bitstream from a CramFS partition to memory, much like the fsload command does. Something similar to fpga_load() would be useful, some kind of fs_load(buffer, length, partition, filename).
Good old Unix tradition is to provide small and simple tools which perform one task, doing this very well, and which can easily be combined. So in the first step you will load the image file from cramfs into RAM, and in the second step you use the FPGA command to boot your FPGA.
What exactly is your problem?
Best regards,
Wolfgang Denk

On Tuesday 18 July 2006 11:44, Wolfgang Denk wrote:
In message 200607181054.37865.laurent.pinchart@tbox.biz you wrote:
common/cmd_fpga.c and common/fpga.c are used to configure the FPGA from an in-memory configuration bitstream. What I'm looking for is a function to load the bitstream from a CramFS partition to memory, much like the fsload command does. Something similar to fpga_load() would be useful, some kind of fs_load(buffer, length, partition, filename).
Good old Unix tradition is to provide small and simple tools which perform one task, doing this very well, and which can easily be combined. So in the first step you will load the image file from cramfs into RAM, and in the second step you use the FPGA command to boot your FPGA.
Agreed.
What exactly is your problem?
My problem is to load the image file from cramfs into RAM from a C function. The fsload command can be used from the command line (or through bootcmd, preboot, ...), but I haven't been able to find a simple API to load the image file from cramfs into RAM. cramfs_load() takes a struct part_info pointer which I don't know how to provide, and I haven't found a way to get the size of a file to allocate the buffer using malloc.
Best regards,
Laurent Pinchart

In message 200607181157.10015.laurent.pinchart@tbox.biz you wrote:
My problem is to load the image file from cramfs into RAM from a C function.
C'me on. All commands are called from the main interpreter loop, with a standard set of arguments which closely follows standard C's main() syntax. Calling a command handler from C is not more than a beginner's exercise.
The fsload command can be used from the command line (or through bootcmd, preboot, ...), but I haven't been able to find a simple API to load the image file from cramfs into RAM. cramfs_load() takes a struct part_info pointer
Just use the functions as they are used called by the command parser, then.
Best regards,
Wolfgang Denk

On Tuesday 18 July 2006 13:25, Wolfgang Denk wrote:
In message 200607181157.10015.laurent.pinchart@tbox.biz you wrote:
My problem is to load the image file from cramfs into RAM from a C function.
C'me on. All commands are called from the main interpreter loop, with a standard set of arguments which closely follows standard C's main() syntax. Calling a command handler from C is not more than a beginner's exercise.
I thought the do_* functions (do_jffs2_fsload here) were not supposed to be used outside the interpreter. Thanks for the explanation.
The fsload command can be used from the command line (or through bootcmd, preboot, ...), but I haven't been able to find a simple API to load the image file from cramfs into RAM. cramfs_load() takes a struct part_info pointer
Just use the functions as they are used called by the command parser, then.
Thanks.
Best regards,
Laurent Pinchart

In message 200607181808.35581.laurent.pinchart@tbox.biz you wrote:
I thought the do_* functions (do_jffs2_fsload here) were not supposed to be used outside the interpreter. Thanks for the explanation.
Why not? Of course, in most cases much simpler interfaces exist which then get used. But instead of repeating the mtdparts_init(), jffs2_part_info(), cramfs_check()logic before you can finally call cramfs_load() it is IMHO perfectly legitimate to call do_jffs2_fsload() with manually provided argc / argv areguments.
Best regards,
Wolfgang Denk
participants (2)
-
Laurent Pinchart
-
Wolfgang Denk