Re: [U-Boot] serial : Device tree support for multiple serial devices.

2012-01-30 Thread hanumant

On 1/30/2012 10:35 AM, Simon Glass wrote:

What I did for now was to implement a new fdt_serial.c file which
defines 4 separate sets of function (each set containing putc, getc,
etc.) with the device pointer built in to those functions. It's really
ugly, and is what eserial does. Those functions look up the device
tree during init and redirect to the real serial driver's functions of
the same name.

I could probably rustle up a patch if it would help.


Thank you a patch would help a great deal.

Thanks
hanumant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] serial : Device tree support for multiple serial devices.

2012-01-23 Thread hanumant

Hi

The board that I am working on has multiple serial ports.
I am trying to use device trees to configure board resource of these 
ports as well as the serial framework. So the driver doesnot know 
apriori the number of uart ports on the board. But querries the device 
tree for it.I am facing the following issues.


1) Ports are memory mapped and each port has its own register space.
As such the serial framework apis dont provide for passing a port id at 
the time of the call. So how do i access the correct register space for 
the corresponding port?. Or should i define for my own set of apis to be 
called by clients, allowing me to access specific ports corresponding 
address space, and use the serial framework api's only for the default 
serial console?


2) the default serial console, also gets configured based on information 
obtained from the device tree, at run time. If i keep a global 
representation of the default serial console with its base address etc, 
it will still have to be reinitialized after relocation. The 
default_serial_console() gives me an opportunity to reinitialize the 
global structure. Is that the way to go?


Thanks
Hanumant


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] device tree compilation problems.

2012-01-22 Thread hanumant

Hi

   I am getting DTC when compiling dts file with CONFIG_OF_CONTROL.
The message says that it cannot find skeleton.dtsi though its placed
in the same directory as the dts file. I notice that if i remove this
line from the dts Makefile, the error disappears


 $(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
-   cat $ | $(CPP) -P $(DTS_CPPFLAGS) - $@.tmp
-   $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $@.tmp
-   rm $@.tmp
+   $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $

Has anyone faced this issue?

Thanks
Hanumant

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] SSBI driver

2011-11-17 Thread hanumant
Hi

   I am trying to implement a SSBI driver for a board. . The driver is 
meant to be portable to multiple boards by the same vendor.
Keeping this in mind

1)Would drivers/misc/ be the right location to implement this driver?
2)If not can I make a ($vendor)-common in the cpu directory to implement 
the driver given that the driver is going to be applicable for multiple 
socs by the same vendor. ie have something like the below.
have arch/arm/cpu/armv7/($vendor)-common  arch/arm/cpu/armv7/($SOC).
I believe there is already precedent for this?

Any input is appreciated.

Thanks
Hanumant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Error in using linux\ioport.h

2011-11-04 Thread hanumant
Hi

If I include linux\ioport.h I get errors because resource_size_t type 
has not been defined.
I believe it should be defined in linux\types.h?

Thanks
Hanumant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Porting U-boot

2011-10-31 Thread hanumant

I am trying to port u-boot to multiple soc/boards from an arm vendor.
I would appreciate any input on the following approach

1)The controller instance on various SOC are the same with minor 
differences in the fifo size, gpios, clocks.

2)In order to help the porting effort, my idea is to add soc/board 
neutral driver header files under the include/asm/ directory.
Possibly creating a vendor directory under there ie
arch/arm/include/asm/($vendor)/
(Different from the soc specific header files arch-$SOC)

3)Implement driver in respective driver category drivers/$category

4)Allow the SOC specific files to define the resources for specific 
peripherals based on the header files from 2)

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot