Two techie questions for Pandaboard (ES) owners
Chris Hall (132) 3554 posts |
That’s not necessarily conclusive, Whilst the test booting into RISC OS is not conclusive, I then powered off the board, booted into Linux, pressed RESET and it hung. Before the x-loader could start you had to unplug and replug the SD card. Hence cannot be related (just) to RISC OS initialisation as it happens as well with Linux. There’s a teeny switch, SW1 that should swap the boot order to 11001101 Flipping this switch appeared to make no difference. Getting a stable badge should be hard I agree. Not sure whether you mean Omega or A9home :). A half-way house for the Pandaboard would (probably) be useful where a ‘snapshot’ ROM image is provided, albeit beta, where nothing speculative has been embarked upon, to provide a known, consistent base with documented idiosyncrasies that users that need (otherwise) to download the daily build can download knowing that (at least) no new problems should be encontered. Then if a problem is encountered that is not ‘on the list’ it is a new issue to flag up. At the moment one simply assumes it is a quirk of tinkering and one sticks with PandaLand or whatever. |
Jeffrey Lee (213) 6048 posts |
My Pandaboard rev A6 seems to suffer from excessive green speckling, at all resolutions & pixel rates. Instead of one vertical line down the middle of the colour picker (as with Malcolm) I have three (splitting it into quarters), and the default desktop background has speckles everywhere. Not sure yet if RISC OS, my slightly dodgy MLO/u-boot, or the hardware are to blame – I’ll need to do some more testing with some other OS’s. |
Chris Hall (132) 3554 posts |
If it is any help, I have a Pandaboard ES revision B1 (currently running PandaLand) and can do some testing if that would be helpful. My monitor is 1920×1080 though so I cannot help with green speckles. It would probably help if there was a ‘standard’ SD card image for the Pandaboard – like the RC series for the Pi – so that user experiences can be collected and documented so that everyone knows exactly what the ‘known issues’ are so that newly found ‘bugs’ can be identified. Possibly more than one image to cater for different board revisions? If the necessary firmware source (for licensing reasons) can be hosted separately then the SD card image can be quite small when zipped – perhaps 18Mbytes. With some thought, it could have several versions of u-boot/MLO in the FAT partition with the most prevalent version as the default and some instructions in case of earler board revisions. |
Conor (2370) 36 posts |
A ‘standard’ SD card image for the Pandaboard would be like heaven for those of us who have relatively little to no experience with RISCOS. Malcolm and Andrew (R-Comp) have been great helping me get my Panda off the ground but it has been an extremely frustrating couple of days. When I compare my first experience getting the Pi going to this, it is no comparison! From an outsiders perspective, and I understand there will be a few more hoops to jump through because of the firmware, if the RISC OS community wants to keep attracting new users and keeping them (like myself), it is imperative to get a standard SD card image for the Panda for people to use. Does anyone know why an SD card image is available for the Pi and not the Panda? Too few people to work on it? Licensing fees? Something else? |
Jeffrey Lee (213) 6048 posts |
Three reasons, I suspect:
The Pi image is also a bit special in that it contains lots of added extras which aren’t part of the core disc image. To include those extras in disc images for any other machines would probably involve a fair bit of extra admin time to go through and check/renegotiate all the licenses. I suppose one potential solution to the bandwidth problem (and potentially the licensing one) would be to embrace PackMan more than we’re currently doing. I.e. produce several small, machine-specific SD card images that contain just enough to allow the system to boot and download the rest via PackMan. If the user was given some choice over what to install then that would cut down on the bandwidth cost of setting up a new system. And if all updates could be applied via PackMan then that would help discourage people from re-downloading the full base image in order to apply updates, when all that’s changed are a handful of files. And I guess if we wanted to really pinch pennies we could reduce the ROM to its bare minimum and have all the modules softloaded – that way people wouldn’t be re-downloading full ROM images just because one module has changed. |
Conor (2370) 36 posts |
Jeffrey, if the case is a matter of money with regards to bandwidth, I’m sure there are enough people in the RISC community who would be willing to throw a few quid in the hat. I’d gladly pledge £25 a month if it meant that ROOL would offer SD card images (different ones for each revision) for the Pandabaord. Bootloaders aren’t that difficult to swap out in an image so I’d say that probably isn’t too big of a deal. However, your first idea is probably the most correct. Loads more people have a Pi than a Pandaboard and with Pandaboard being difficult to come by lately, the number is not growing at all. It is too bad because in my instance, I’m a secondary school teacher and I’m doing my best to get students interested in RISC. Most of them have RPis but if they really want to delve deep into RISC and use it as a workstation then they are probably going need a Panda… it’s the reason I bought one. I want more horsepower however getting RISCOS up and running as a functional OS on the Panda is killing me. I was reminded of this again tonight when I did a fresh install to track down a bug on my Pi. So easy to do… and then I think about the last few days I have spent with my Panda and how I am annoying the heck out of Malcolm and Andrew with (probably) stupid questions. Please ROOL, please come up with SD card images for the Pandaboard. As a “newbie”, an outsider to RISCOS, and a foreigner (I’m Canadian living in Canada), do your operating system a huge favour and make life as easy as possible for your users. Linux had to learn the hard way, anyone who used Linux back in 1994 through 1999 can attest to the fact that it was a pain the backside to get it going and running properly. Few people used it and those of us who did, me included, found it painful most days. It wasn’t until the install was made easier, the setup of peripherals was made easier, and more boards (like the different versions of the Pandaboard) were supported that people truly began to use it on a constant basis. Now look, even my 79 year old Aunt knows what Linux is… doesn’t use it but knows about it. I have been using RISC on a daily basis on my Pi for months now. I love it. It is the first computer I turn on in the morning and I am throwing my two cents into the hat because I care about the future and about getting new people interested in this great operating system. |
Rick Murray (539) 13817 posts |
I think this is why: A requirement of the GPL is that the source is included, but if the SD was built from a binary then it can be difficult to determine exactly what source built the supplied binary, and this needs to be checked and confirmed for every release. It can’t be “the current bootloader sources”, it must be the exact sources that built the executables supplied. Pretty much what it says here. |
Conor (2370) 36 posts |
Thanks for posting that Rick. Saying that, there has to be a way to make this process for the Panda/Beagle easier… |
Chris Hall (132) 3554 posts |
We do have a matching source and binary (from Chris Gransden via CJE) so that’s not the issue. The source is 70Mbytes so would probably have to be offered rather than bundled (either is acceptable). My solution would be to offer the source as a printed document via lulu.com at zero cost with the user just paying postage or downloading the source as a PDF at zero cost (lulu.com offer both printed books and e-books with zero set-up costs – GNUPL does say ‘distribute source … in any medium’), This would be a bandwidth cost of zero. I think it is simply ROOL time and resources unfortunately. The only solution at the moment is to purchase the PandaLand SD card and subscribe to the PandaLand scheme. |
Conor (2370) 36 posts |
I have done just that, subscribing to PandaLand that is… |
Chris Hall (132) 3554 posts |
As have I. cheaper for ROOL to host the ROMs + disc image as separate downloads than to have many large machine-specific SD card images A zipped SD card image is no larger than the HardDisc4 content plus ROM (about 14 Mbytes). With thought that can be cut down significantly – if the user loads the HardDisc4 ‘utility’ onto the FAT partition of the SD card separately and on first boot this is expanded automatically into a RAM disc and copied thence onto the SDFS partition (overwriting the expand and copy on first boot instruction), then the hosted SD card image can be not much bigger than the ROM size – about 2 to 4 Mbytes. If you ask the user to copy the rom image onto the FAT partition of the SD card as well then the SD card image, zipped, should be no more than a few tens of kbytes. There’s no single bootloader version which is known to work with all PandaBoard revisions With the hosted SD card image just a few tens of kbytes, several versions can easily be hosted… Different firmware, different SD card sizes etc. etc. It would mean a ‘recommended’ snapshot rom for the Panda as well the daily build. We could even ask users to vote on whether the ‘snapshot’ rom should be rolled forward as things like the sound system (28 June 2014, ticket #347) get fixed. |
Conor (2370) 36 posts |
Great ideas Chris! Now, who do we speak with to get the ball rolling? I’m willing to help in anyway that I can… |
Chris Hall (132) 3554 posts |
The initiative has to be with ROOL: they must ask permission (from Chris Gransden) to distribute his sources (he has tweaked them and added bits) as ROOL would be the ones distributing it. If they want me to do the work of turning the source into a PDF and uploading it to lulu I can do that (no one is ever going to download it, print it out and type it in, surely). I can also put together a series of zipped SD card images if they want to host them, along with instructions. |
Conor (2370) 36 posts |
I’d like to help with the instructions because as someone who is relatively new to RISC OS, I can definitely give some input as to how much explaining is really needed for new users. That is one thing that Andrew@R-Comp and myself have found over the last few days and our PandaLand discussions… I really didn’t get a lot of how RISC works as an operating system and therefore didn’t understand a lot of the instructions that Andrew was giving to me. He thought he was being clear and to someone who has used RISC, I’m sure he was clear as day but to someone like me, more explanation was needed. Alright, so ROOL, what do you think? :) |
Chris Evans (457) 1614 posts |
Conor: I think the biggest problem is the resources within ROOL and in particular ‘time’ I know they have quite a long list of things they are planning to and many more they want to do. |
Jeffrey Lee (213) 6048 posts |
I think you’ve misread things a bit, there. The “in any medium” statement applies to distributing just the source code. But if you look at sections 2 and 3 then you’ll see that if you distribute (modified) binaries then you must ensure the source code (when requested) is made available in a machine-readable form, in a format that’s customarily used for software interchange. Considering that the original sources are coming from a git repository it would make more sense to just create a repository on github (which is free for public projects) and host the sources there. Hell, if we’re using unmodified sources then we can just point people at the upstream repository. All perfectly fine as far as the GPL is concerned; the only thing ROOL might need to do to make sure they’re fully covered is to make sure they have a local (offline) copy of any released sources just in case github vanishes before the GPL’s 3 year source availability limit is reached. And if anyone requests a physical copy then writing the sources to an SD card/CD-ROM/USB stick and charging them for that wouldn’t be significantly more of a hassle than issuing an order for them through lulu.
I thought the goal was to host a ready-to-go SD card image? The more steps the user has to go through, the less likely they are to try it, and the more likely they are to mess things up. |
Conor (2370) 36 posts |
It seems from what I’m reading that this Pandaboard issue is just the tip of the iceberg. RISCOS appears right in between a highly successful OS like OpenBSD (though their ‘ruler’ is a tad mental) and a dying one like Haiku. Jeffery, so what Rick mentioned about licensing can be worked around? If that is the case, then yes a ready-to-go SD card image should be the goal. I had difficulty sleeping last night and I spent a few more hours working with my Panda… I have a somewhat working desktop but it is an unbelievably silly process to get to that point. When compared to the Pi, it is like night and day and I have no doubt that an IMG could be make up in a matter of days if needed for several different versions of the Panda. Perhaps RISC should adopt the idea of a Hackathon. OpenBSD has had them for 15 years now and are sponsored by every day OpenBSD users like myself. I have used OpenBSD since 2003 and donate small amounts each year to help send people to these hackathons so they can improve the operating system. Since most RISC programmers are in the UK, Germany, and the Netherlands, it wouldn’t be as expensive to get people together as it is with OpenBSD. |
Chris Hall (132) 3554 posts |
Considering that the original sources are coming from a git repository it would make more sense to just create a repository on github Yes, that’s probably even less likely to be useful to anyone but then we’re not expecting or really wanting anyone to use the sources in any case. I agree it is better to have a complete SD card image rather than a ‘kit of parts’ but the principal thing is to have a consistent and identical card image in use by everyone so that support is easier – just the bandwidth to worry about though. |
Jeffrey Lee (213) 6048 posts |
Complying with the GPL is a bit of a hassle, but it’s by no means a show stopper. I think the big thing I missed from my list of reasons why we don’t have a Pandaboard SD card image (and the main reason for why we don’t have lots of other things) is that ROOL simply don’t have enough time to do many of the things they/we want to do – see Chris Evans’ discussion re: facilitator bounties. Investing money in that would probably reap greater rewards than trying to organise hackathons, at least at this stage of RISC OS’s life. Either that or you need to find some way of enticing more people to work on the OS – at the moment I could probably count on one hand the number of active OS developers. Everyone else is either disinterested, too busy, or too scared/inexperienced. |
Chris Hall (132) 3554 posts |
Active OS developers are, indeed, in short supply and it is not a simple matter to identify a task in a way that less experienced people can do it without very close supervision (which defeats the object). However it is a worthwhile thing to do as it is the only way forward. ROOL cannot do everything and there are people out there (like me) with lots of time but (for example) no clear idea of the exact way in which ROOL would require a prospective SD card image for the Pandaboard to be put together before they would be prepared to host it. This is a task that can be done by a non-programmer but only if they know ROOL’s idiosynchrasies and preferences. I know they aspire to host such an image and are more fastidious in licensing compliance than others who already sell such things. As I don’t want money, the bounty system won’t work for me. |
Rick Murray (539) 13817 posts |
Good grief – 70MB for a bootloader? Or is that including all the other rubbish not relevant to the build, like DEC and x86 startup code?
Seriously? It wasn’t so long ago we were thinking a guy called David was crazy for (allegedly) posting a printout of his source code to ROOL.
No, they don’t. If it is a modification of GPL software, it is still GPL software. As such, the sources should be available to us right now. If it is not, then that is a breach of the GPL. “b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.” (and other parts I can’t be bothered copy-pasting).
It is still GPL.
Yup. His problem (the provision of source code) will become ROOLs problem. Note that the GPL specifies the provision of the corresponding machine-readable source code; so it will not suffice to point people to a third-party copy (Chris’ for instance) unless you are absolutely sure that the code and the executable match up. Oh, and “source code” can mean more than just the C and assembler files, it by necessity must include everything necessary for building the software – scripts, obey files, blah blah. Read section 3.
I would imagine:
Let’s put it like this – making an SD image is not difficult. As you say, it could probably be automated to the point where a non-programmer could do it, or better yet, just another tickbox in !Builder.
Good on them. At least we know our bounty donations are less likely to be swallowed up in legal fees if somebody decides to pick a fight with ROOL. Those who sell with fewer morals tend to be…
At least ROOL is trying to do the right thing here. |
Rick Murray (539) 13817 posts |
Well, in binary you could count up to 31 people with one hand. ;-) |
Chris Hall (132) 3554 posts |
is properly licence compliant there is no need (at this stage) for more than the rom and the standard HardDisc4 image so it’s only the xloader and MLO source that has to be offered. The rest is already ROOL’s. |
David Feugey (2125) 2709 posts |
For Pi, Beagle and Panda, it would be good to have bootloader, rom, disc image and a combination of the three, ready to run. TO be honest, I don’t really like the current Pi disc image: too much software. It’s a good way to attract new users, but not for power users. |
Steve Fryatt (216) 2103 posts |
Considering that the original sources are coming from a git repository it would make more sense to just create a repository on github Er, what? A git repository would be less useful than a copy of the source as a PDF? |