[U-Boot] Fw: Re: Re: [PATCH] add u-boot sja1000/can support
Hi mike, It seems there's a big difference between my current project and u-boot common usage. I can only enjoy the patch myself now
i want to get a packet from usb/network, then redirect it to can bus. So blocked write/read of can is not allowed.
On Monday 26 October 2009 00:48:39 miaofng wrote:
Thanks for careful review. I'll resend the patch according to your remarks except follwing: 1)
+int register_candev(struct can_device *dev)
use "can" or "candev", dont mix the two
answer: register_candev is origin from register_netdev(...). CAN is something like network, it may has high level protocols such as open-can and etc, so i want to keep that story.
i know what CAN is. the Linux approach makes sense because they've architected CAN at the socket() layer, and all of the network layers are written with common coding style. but there is no such socket/network layer in u-boot so the can/candev distinction isnt necessary.
+int sja1000_interrupt(struct can_device *dev)
u-boot is a polled architecture, not an interrupt based one. i guess this driver needs rewriting to do that.
answer: no, i want to keep that structure. Then linux drivers can be ported to u-boot easily. take an example, in sja1000, i only need to replace "_net" to "_can" at most of time. To gain this convience, i added the wrap layer of can_core.c.
the convenience factor doesnt mean you can ignore u-boot design principles. the default behavior for all frameworks/drivers is a polled mode because it's simple and straightforward. not all u-boot ports even support interrupts
In order to work in u-boot polled mode, people only need to call sja1000_interrupt periodly. It works fine on my board.
erm, no, that's not how things work in u-boot. u-boot processes commands given to it (either via scripts or from user input), and each command does not return until it is completely done processing. there is no "backgrounding" of drivers -- u-boot is not an OS and it is not threaded. that means any CAN operation does not return until it has finished sending/receiving everything it was told to. -mike
miaofng wrote:
Hi mike, It seems there's a big difference between my current project and u-boot common usage. I can only enjoy the patch myself now
Yes, can you describe your use-case. CAN in U-BOOT, so far, was just used to send or receive one or a few messages, mainly for testing purposes.
i want to get a packet from usb/network, then redirect it to can bus. So blocked write/read of can is not allowed.
You have that working?
Wolfgang.
Wolfgang Grandegger wrote:
miaofng wrote:
Hi mike, It seems there's a big difference between my current project and u-boot common usage. I can only enjoy the patch myself now
Yes, can you describe your use-case. CAN in U-BOOT, so far, was just used to send or receive one or a few messages, mainly for testing purposes.
what i want to do is something like a protocol gateway. It converts the data from one type to another. u-boot has support so many cpu/board/...., i thinks it can do much more tasks than just for testing purposes. It could be a non-OS based software plaform :)
i want to get a packet from usb/network, then redirect it to can bus. So blocked write/read of can is not allowed.
You have that working?
not yet. i have finished usb and can part.
miaofng wrote:
Wolfgang Grandegger wrote:
miaofng wrote:
Hi mike, It seems there's a big difference between my current project and u-boot common usage. I can only enjoy the patch myself now
Yes, can you describe your use-case. CAN in U-BOOT, so far, was just used to send or receive one or a few messages, mainly for testing purposes.
what i want to do is something like a protocol gateway. It converts the data from one type to another. u-boot has support so many cpu/board/...., i thinks it can do much more tasks than just for testing purposes. It could be a non-OS based software plaform :)
Well, U-Boot is a bootloader and I strongly suggest to use Linux for that purpose. Nevertheless, maybe a simple generic CAN framework could be useful for both, normal testing purposes and your special app. Some time ago I wrote a simple framework supporting the SJA100 and the i82527. I will try to find it now.
Wolfgang.
Dear miaofng,
In message 4AE5A449.7040300@gmail.com you wrote:
what i want to do is something like a protocol gateway. It converts the data from one type to another.
Use an OS for this purpose. U-Boot is just a boot loader.
u-boot has support so many cpu/board/...., i thinks it can do much more tasks than just for testing purposes. It could be a non-OS based software plaform :)
Yes, it can do that. You can also use a microscope to drive a nail into a board. But neither U-Boot nor the microscope would be the adequate tool for the respective purposes.
You have that working?
not yet. i have finished usb and can part.
Don't waste your time. Use an OS. Use Linux, where all this is available abre ready for use now, without additional efforts.
Best regards,
Wolfgang Denk
Dear "=?utf-8?B?bWlhb2ZuZw==?=",
In message 200910261647227347739@gmail.com you wrote:
Hi mike, It seems there's a big difference between my current project and u-boot common usage. I can only enjoy the patch myself now
i want to get a packet from usb/network, then redirect it to can bus. So blocked write/read of can is not allowed.
On Monday 26 October 2009 00:48:39 miaofng wrote:
Thanks for careful review. I'll resend the patch according to your remarks except follwing: 1)
+int register_candev(struct can_device *dev)
use "can" or "candev", dont mix the two
answer: register_candev is origin from register_netdev(...). CAN is something like network, it may has high level protocols such as open-can and etc, so i want to keep that story.
i know what CAN is. the Linux approach makes sense because they've architected CAN at the socket() layer, and all of the network layers are written with common coding style. but there is no such socket/network layer
Arghhhh...
Your quoting is as broken as your (missing or incorrect) In-reply-to: and References: file headers. Please make sure to read http://www.netmeister.org/news/learn2quote.html, and make sure not to corrupt mail threads.
Thanks.
Best regards,
Wolfgang Denk
participants (3)
-
miaofng -
Wolfgang Denk -
Wolfgang Grandegger