Re: [Qemu-devel] [RFC] i.MX233 / olinuxino support

2012-12-24 Thread M P
On Tue, Dec 11, 2012 at 3:11 PM, Peter Maydell peter.mayd...@linaro.orgwrote:

 On 11 December 2012 15:08, M P buser...@gmail.com wrote:
  On Tue, Dec 11, 2012 at 2:57 PM, Peter Maydell peter.mayd...@linaro.org
 
  wrote:
  Showing 11 changed files with 2,236 additions and 0 deletions.
 
  That commit absolutely has to be broken up into a coherent set of
  smaller patches; it is far too big to code review as it stands.
 
 
  Well I pondered that, but really I don't see how to split that since they
  are all new files.., and all the bits are part of one 'unit'.. Any
  suggestion ?

 The usual approach is one of:
  * a patch per device, then one patch at the end with the board model
 or if you have a lot of devices:
  * a patch per device for a few basic devices (uart etc)
  * then a patch for a board model using those and able to boot
a very stripped down kernel
  * then add more complicated devices later, with a patch per
device which adds the device source file and modifies the board
model to instantiate it

 Bear in mind that QEMU should compile at every stage between every
 patch; it's not enough for it to just compile at the end when all
 patches are applied.


Hi guys. I've reworked the patch to follow the coding rules (I hope) and
split it
into devices, and verified they all work independently.

Could you please have a quick eyeball before I post the patches on the
list, if
appropriate ?
I've added quite a few functional things since the last request, I got a
pretty good
emulation working now.

https://github.com/buserror-uk/qemu-buserror/commits/dev-imx233

Thanks,
Michel



 thanks
 -- PMM



[Qemu-devel] [RFC] i.MX233 / olinuxino support

2012-12-11 Thread M P
I've added imx23 support to qemu, with quite a lot of working peripherals,
and enough to boot linux with SD card and USB working. There are bits
missing (audio, video outputs) but it's otherwise working pretty well.

I've collated and cleaned the patches onto this github branch, I'd
appreciate any comments and/or complementary work before I submit the
patches for merging here...

https://github.com/buserror-uk/qemu-buserror/commits/dev-imx233

Michael


Re: [Qemu-devel] [RFC] i.MX233 / olinuxino support

2012-12-11 Thread Peter Maydell
On 11 December 2012 13:08, M P buser...@gmail.com wrote:
 I've added imx23 support to qemu, with quite a lot of working peripherals,
 and enough to boot linux with SD card and USB working. There are bits
 missing (audio, video outputs) but it's otherwise working pretty well.

 I've collated and cleaned the patches onto this github branch, I'd
 appreciate any comments and/or complementary work before I submit the
 patches for merging here...

 https://github.com/buserror-uk/qemu-buserror/commits/dev-imx233

Showing 11 changed files with 2,236 additions and 0 deletions.

That commit absolutely has to be broken up into a coherent set of
smaller patches; it is far too big to code review as it stands.

You don't seem to be following the QEMU coding style. (CODING_STYLE
and scripts/checkpatch.pl may be of use).

Information on how to test the board model would be good. Also
unit tests, maybe?

Are you going to be sticking around to help maintain and improve
the board model in the future?

http://wiki.qemu.org/Contribute/SubmitAPatch has more pointers
on patch submission.

thanks
-- PMM



Re: [Qemu-devel] [RFC] i.MX233 / olinuxino support

2012-12-11 Thread M P
On Tue, Dec 11, 2012 at 2:57 PM, Peter Maydell peter.mayd...@linaro.orgwrote:

 On 11 December 2012 13:08, M P buser...@gmail.com wrote:
  I've added imx23 support to qemu, with quite a lot of working
 peripherals,
  and enough to boot linux with SD card and USB working. There are bits
  missing (audio, video outputs) but it's otherwise working pretty well.
 
  I've collated and cleaned the patches onto this github branch, I'd
  appreciate any comments and/or complementary work before I submit the
  patches for merging here...
 
  https://github.com/buserror-uk/qemu-buserror/commits/dev-imx233

 Showing 11 changed files with 2,236 additions and 0 deletions.

 That commit absolutely has to be broken up into a coherent set of
 smaller patches; it is far too big to code review as it stands.


Well I pondered that, but really I don't see how to split that since they
are all new files.., and all the bits are part of one 'unit'.. Any
suggestion ?



 You don't seem to be following the QEMU coding style. (CODING_STYLE
 and scripts/checkpatch.pl may be of use).


I'll study the coding style. I have to say I did a bit of cut/paste from
other files and 'tried' to stick to what I've seen, and otherwise defaulted
to kernel mode..



 Information on how to test the board model would be good. Also
 unit tests, maybe?

 Are you going to be sticking around to help maintain and improve
 the board model in the future?


Yes I'd definitely would want that, as well as add imx28 -- I did the
mini2440 qemu support years ago, but let it diverge and
always regretted that as now it's it would require more or less a rewrite...



 http://wiki.qemu.org/Contribute/SubmitAPatch has more pointers
 on patch submission.


Thanks, thats exactly the sort of information I wanted :-)



 thanks
 -- PMM


Michael


Re: [Qemu-devel] [RFC] i.MX233 / olinuxino support

2012-12-11 Thread Peter Maydell
On 11 December 2012 15:08, M P buser...@gmail.com wrote:
 On Tue, Dec 11, 2012 at 2:57 PM, Peter Maydell peter.mayd...@linaro.org
 wrote:
 Showing 11 changed files with 2,236 additions and 0 deletions.

 That commit absolutely has to be broken up into a coherent set of
 smaller patches; it is far too big to code review as it stands.


 Well I pondered that, but really I don't see how to split that since they
 are all new files.., and all the bits are part of one 'unit'.. Any
 suggestion ?

The usual approach is one of:
 * a patch per device, then one patch at the end with the board model
or if you have a lot of devices:
 * a patch per device for a few basic devices (uart etc)
 * then a patch for a board model using those and able to boot
   a very stripped down kernel
 * then add more complicated devices later, with a patch per
   device which adds the device source file and modifies the board
   model to instantiate it

Bear in mind that QEMU should compile at every stage between every
patch; it's not enough for it to just compile at the end when all
patches are applied.

thanks
-- PMM