No início de dezembro de 2021, recebemos uma notícia sobre os componentes eletrônicos necessários que ainda estão em falta. Temos um número total de 22 componentes em falta, e alguns deles estão presentes na lista várias vezes, como o MOSFET (https://en.wikipedia.org/wiki/MOSFET).
Abaixo uma lista detalhada dos componentes em falta:
7 por placa: MOSFET – DMN3730U-7 N 750mA 30V POWER MOS – Diodes
9 por placa: Trans MOSFET – SI4925DY P-CH 30V 5.3A 8-Pin SOIC – ON SEMICONDUCTOR
4 por placa: Field Effect Transistor –NDC7002N MOSFET 2N-CH 50V 0.51A SSOT6 – ON SEMICONDUCTOR
3 por placa: IRLML6346TRPBF – N-Channel 30 V 3.4A (Ta) 1.3W (Ta) – Infineon Technologies
Enquanto a ACube Systems está procurando os 22 componentes em falta, em contato com vários distribuidores, nós da Comunidade Power Progress estamos tentando ajudar a obtê-los também. O principal problema que estamos enfrentando não é encontrar cada componente, mas sim que a entrega estimada na maioria das vezes é de seis meses ou mais. Porisso, estamos avaliando a substituição de alguns dos componentes para obtermos um prazo de entrega mais razoável. Caso você possa ajudar a realizar esta tarefa, contate-nos.
QEMU a todo vapor, com KVM, no processador NXP T2080
Graças a Fabiano Rosas, Cédric Le Goater e Zoltan Balaton (ver discussão em https://lists.gnu.org/archive/html/qemu-ppc/2021-12/msg00231.html) agora é possível rodar máquinas virtuais em velocidade quase nativa com o QEMU no nosso kit de desenvolvimento NXP T2080RDB, que usa exatamente a mesma CPU que o nosso laptop.
Esta grande conquista foi possível graças ao apoio da KVM (https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine) que permite que a máquina virtual utilize diretamente a CPU sem a necessidade de passar tempo a emulando.
O suporte KVM para PowerPC Book3e e6500 CPUs será introduzido pela primeira vez a partir do kernel linux 5.16+ e com a próxima versão do QEMU, muito provavelmente v7.0. Se você quiser experimentar agora, você deve obter o candidato de lançamento do kernel 5.16 e compilar você mesmo QEMU a partir do branch principal do GIT.
Nós compilamos com sucesso o kernel e o QEMU e depois testamos algumas máquinas virtuais rodando Linux para PowerPC 64 bit em modo Big Endian. Acima, você pode ver uma captura de tela do QEMU rodando três máquinas virtuais com KVM ativado. O sistema host é nosso NXP T2080RDB dev kit que roda Debian SID PPC64, depois há uma VM com Debian SID PPC64 (inferior-direita), depois OpenSUSE Tumbleweed PPC64 (inferior-esquerda), e finalmente VOID Linux PPC64 (superior-direita).
Note que o suporte da KVM à família e6500 PowerPC ainda está em andamento, por isso pode alguns ajustes podem ser necessários antes de ser considerado confiável.
Nossas últimas palestras – Outubro e Novembro de 2021
Open Power Summit 2021 NA
Prepare-se para migrar para a arquitetura Open Hardware Power Architecture.
Graças aos nossos apoiadores, chegamos lá de novo!
A campanha de doação para financiar três protótipos atingiu seu objetivo no domingo 24 de outubro com uma surpreendente aceleração final graças à maior doação já recebida, que nos fez pular em nossas cadeiras quando a vimos. Obrigado a todos vocês e, especialmente, muito obrigado ao Wiktor Glowacki!
Transferimos o dinheiro arrecadado pela campanha à ACube Systems, a empresa que selecionamos para a jornada desafiadora para fazer um notebook PowerPC. No momento, estamos enfrentando alguns atrasos devido às dificuldades da cadeia de fornecimento da indústria eletrônica (veja nosso post sobre isso), e a ACube está no momento aguardando os últimos componentes eletrônicos para finalmente construir as três placas.
Agora estamos prontos para lançar a próxima campanha de arrecadação, para financiar os testes de hardware, com meta de 14.000 euros.
A nova campanha começa hoje, e as doações serão transferidas para a ACube. Nossa esperança é concluir esta nova campanha em menos de 10 meses, mas isso dependerá em grande parte de seu apoio.
Logo após testarmos os três protótipos, publicaremos uma versão atualizada dos diagramas eletrônicos em nosso repositório GitLab, para que o projeto disponível ao público seja uma versão meticulosamente revista.
Estamos relativamente confiantes de que as doações se acelerarão quando pudermos mostrar publicamente os protótipos físicos, pois isso deverá melhorar a credibilidade do nosso projeto.
Lembramos que depois desta nova campanha para realizar os testes de hardware necessários, a próxima campanha é para a certificação de hardware CE com uma meta de 12500 euros, e então finalmente estaremos prontos para a produção em massa!
Um grupo de gurus para configurar o U-Boot
A nova campanha de arrecadação financiará o trabalho realizado pela ACube Systems e seu projetista de hardware para os testes de hardware.
Esforçaremo-nos bastante para contribuir com o processo de desenvolvimento, trabalhando no boot-loader U-Boot. Esta tarefa é bastante urgente, e estamos atualmente criando um grupo central de voluntários com alguns conhecimentos de U-Boot e árvores de dispositivos necessários para inicializar o hardware.
Como anunciado em um post publicado em 2018, tivemos alguma experiência na configuração do U-Boot quando montamos nosso kit de desenvolvimento, o NXP T2080-RDB. Nossa configuração foi baseada na versão antiga U-Boot originalmente fornecida com o kit (QorIQ SDK v2.0-1703).
Um exemplo dos problemas que estamos enfrentando é que o nosso build atual do U-Boot não inicializa a placa de vídeo, portanto, a única maneira de interagir com o U-Boot é através de um terminal serial remoto. Este problema precisa ser resolvido para melhorar a usabilidade geral da placa-mãe.
Você pode dar uma olhada nos passos que seguimos enquanto trabalhamos com o U-Boot em nosso wiki, e na documentação abrangente e detalhada no site da nossa associação.
Abaixo você pode encontrar um commit feito em 2018 ao U-Boot original, compilado em 2017, que foi fornecido com o NXP SDK v2.0-1703.
O plano é começar a trabalhar na última versão do U-Boot (2021-10), estamos em dúvida se devemos começar pelo repositório oficial da linha principal do U-Boot ou, alternativamente, pelo repositório U-Boot QorIQ. Qualquer conselho sobre qual é a melhor escolha é geralmente bem-vindo (por favor, acrescente um comentário a este post).
Abaixo, você pode encontrar um link para o que trabalhamos em 2018 a fim de iniciar o Linux no NXP Development Kit T2080-RDB:
Qualquer pessoa disposta a ajudar nesta área deverá testar qualquer novo lançamento do kernel Linux para identificar quaisquer mudanças que possam impedir o uso de uma plataforma baseada em CPU NXP T2080, como a placa-mãe do nosso notebook.
Infelizmente, estas tarefas exigem o uso direto de um hardware que monta a mesma CPU usada na placa-mãe do notebook e não podemos dar acesso ao nosso NXP T2080RDB a ninguém. Enquanto esperamos que os protótipos fiquem prontos, pouco podemos fazer nesta área. Mas, mesmo assim, se você estiver interessado em ajudar, pode começar a investigar as diferenças entre as famílias Book3e e Book3s PowerPC, tendo em mente que o T2080 pertence à família Book3e, e especificamente à variante NXP e6500. A principal lista de discussão dos desenvolvedores do kernel Linux é https://lists.ozlabs.org/pipermail/linuxppc-dev/.
Até o presente momento, testamos e usamos com sucesso kernels até 5.12.x no nosso DevKit NXP T2080RDB, mas não conseguimos executar kernels a partir da versão 5.13.x. O kernel simplesmente se recusa a carregar. A causa está atualmente sob investigação. Se você estiver disposto a nos ajudar, por favor, entre em contato conosco e tentaremos conceder acesso ao T2080RDB.
Esta é a página do GitLab onde mantemos registro dos núcleos testados no DevKit.
Precisamos consertar o KVM nos núcleos e6500
By O.T.S.U. – http://openvirtualizationalliance.org/downloads/kvm-logo_300dpi.png, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=24109871
Uma outra área, mas estreitamente ligada ao kernel, é o suporte à KVM (máquina Virtual baseada no Kernel) que atualmente não funciona em nossos testes com o T2080RDB. Este é um recurso essencial, pois permite ao usuário gerenciar máquinas virtuais rodando em velocidade quase nativa, pois não precisam emular a CPU (o KVM é capaz de usar diretamente a CPU do computador host).
Estamos bastante confiantes de que com um esforço relativamente pequeno poderia funcionar porque há pessoas usando KVM em uma CPU muito semelhante, a NXP P5020, que é uma CPU Book3e, especificamente a variante e5500, a CPU NXP da geração anterior. Você pode dar uma olhada abaixo nos resultados alcançados por Christian Zigotzky em seu AmigaOne X5000, um computador atualmente sendo vendido pela A-Eon e baseado no NXP
Screenshot por Christian Zigotzky em seu AmigaOne X5000 (CPU NXP P5040, PPC64, Book3e, e5500) com e QEMU+KVM funcionais.
Outra importante tarefa que planejamos realizar enquanto os protótipos estão sendo preparados é coordenar um grupo capaz de identificar e corrigir problemas que impedem que distribuições Linux para PPC64 (Big Endian ou simplesmente BE) como Debian, VOID ou MintPPC trabalhem na placa-mãe. Outras distribuições Linux como Ubuntu (última versão suportada 14.04) ou Fedora (última versão suportada 28) abandonaram o PPC64 há muito tempo, seria ótimo vê-las novamente suportadas, mas isso é muito ambicioso no momento.
O plano é identificar quais software têm problemas na nossa CPU NXP T2080, muito provavelmente devido a problemas de endianness, identificar o conjunto de mudanças necessárias no código fonte e, em seguida, enviar um patch aos mantenedores do software. O problema que estamos enfrentando é que a grande maioria dos softwares modernos é projetada para funcionar apenas em CPUs Little Endian e, na maioria das vezes, os desenvolvedores não testam seus softwares em nenhuma plataforma Big Endian, também porque elas estão se tornando cada vez mais raras.
Como ter acesso a um T2080RDB pode ser um problema, podemos dizer que em nossa experiência a CPU NXP T2080 se comporta de forma bastante semelhante à CPU G5 (PowerPC 970), a última CPU de 64 bits disponível comercialmente com Altivec, utilizada pela Apple em sua linha de Macs baseados em PowerPC. Se um software funciona bem no G5, há uma grande chance de que ele funcione bem no T2080 também. Claro, o T2080 gasta muito menos energia que G5, mas o G5 seria o companheiro perfeito para realizar a investigação enquanto nossa placa-mãe de notebooks fica pronta. Outra diferença com relação à CPU G5 a se ter em mente é que a T2080 pertence à família de CPU Book3e onde o “e” significa “embedded”, enquanto que a G5 é uma CPU Book3s (aka sPAPR), veja nesta página uma explicação esquemática das famílias PowerPC (https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt). Uma explicação mais detalhada das características da família de CPU Book3e está disponível aqui: https://www.nxp.com/docs/en/user-guide/BOOK_EUM.pdf.
Sugerimos a qualquer pessoa interessada em ajudar no trabalho usar um Power Mac G5 com uma placa Radeon HD, e instalar a versão big endian PPC64 do Debian (https://cdimage.debian.org/cdimage/ports/current/).
Também estamos procurando qualquer pessoa com algum conhecimento sobre como ajustar o software para permitir o suporte Altivec, um ponto flutuante de precisão única e um conjunto de instruções SIMD inteiro que melhoraria muito a experiência do usuário quando suportado.
Nos últimos anos, identificamos algumas áreas-chave de software potencialmente afetadas por questões de endianness que podem ter um forte impacto no uso diário da plataforma, mas três áreas são, em nossa opinião, as mais relevantes:
Qualquer coisa relacionada ao uso de GPUs modernas da AMD Radeon. Selecionamos as GPUs AMD para nossa placa-mãe, já que, de modo geral, estas placas parecem se comportar bastante bem quando usadas em um ambiente big endian. O problema é que qualquer atualização em qualquer coisa relacionada ao uso destas placas de vídeo pode causar erros impedindo qualquer saída de vídeo, por exemplo, atualizações no kernel, no X11, Mesa para software 3D, e mais recentemente Wayland ou Vulkan. Por exemplo, uma atualização recente do SID do Debian para PPC64 quebrou algo e agora não podemos iniciar nenhuma sessão do X11 em nenhuma Radeon HD que tentamos. A causa está sob investigação.
A aceleração de hardware de vídeo também deve ser investigada, então precisaríamos de alguém capaz de lidar com problemas relacionados às tecnologias específicas da AMD Radeon, tais como Unified Video Decoder (UVD), Video Code Engine (VCE) e Video Core Next (VCN). Os softwares que utilizam estas tecnologias e devem ser cuidadosamente investigados são VLC, mplayer e a parte de decodificação de vídeo dos navegadores da Web, a fim de permiti-los reproduzir vídeos em velocidade máxima porque a CPU não é suficientemente potente para decodificar transmissões de vídeo FullHD ou 4K.
Navegadores da Web. Estes softwares são as aplicações mais utilizadas por qualquer tipo de usuário e sem eles o notebook não tem nenhuma chance de ser atraente para ninguém. O navegador mais estável e eficiente na experiência são o ArcticFox e o InterWebSnow.
Atrasos causados pela falta de componentes eletrônicos
Como mencionamos anteriormente, ainda somos vítimas das dificuldades da cadeia de suprimentos da indústria eletrônica. Em julho, informamos que “98% dos mais de 2000 componentes estão agora assegurados e serão entregues dentro do prazo”. A caça ainda está em andamento para os quarenta componentes restantes, e encontrá-los é crucial para não perder o prazo de outubro”. Alguns dos componentes de gerenciamento de energia estão atualmente indisponíveis, então o projetista eletrônico teve que pesquisar substitutos. Em breve, publicaremos o projeto de PCB atualizado rcom todos os novos componentes. A fábrica ainda não recebeu todos os componentes necessários que já encomendamos, e ainda não foi possível encontrar até agora em nenhum lugar do mercado. Em particular, estamos enfrentando problemas para obter o conector HDMI (número de peça 2041481-1) que caberia dentro do chassi do notebook Eclipse. Se você puder nos ajudar a encontrar tal conector, entre em contato conosco. Estamos procurando urgentemente por 3 unidades deste conector para os 3 protótipos. Além disso, também estamos procurando uma solução para a produção de lotes maiores.
Aumento inesperado do preço dos protótipos: 1000 euros
Estamos muito felizes com a generosa participação de todos os doadores que permitiram que a campanha do protótipo ultrapassasse 90% da meta final. Muito obrigado!
Durante nossas pesquisas sobre os mercados eletrônicos em setembro passado, observamos um aumento vertiginoso dos preços. Somos um grupo de hobbistas com zero poder de barganha com os fabricantes de eletrônicos. Até mesmo a respeitada fundação Raspberry Pi foi forçada a aumentar seus preços.
Consequentemente, cada protótipo ficou cerca de 300-320 euros mais caro, incluindo 22% de IVA local, representando um aumento total de 1000 euros, incluindo as taxas do PayPal para os três protótipos. Precisamos aumentar a meta da campanha de 12500 para 13500 euros.
No momento, não podemos dizer se os preços voltarão a baixar e, além disso, quando a atual escassez de componentes eletrônicos acabará. Todos nós esperamos que a situação melhore quando a produção total do lote começar.
Por outro lado, ser forçado a esperar por componentes eletrônicos é bastante compatível com o ritmo lento de nossa campanha de arrecadação, portanto, continue doando!!
Placas de vídeo MXM
Para ter uma idéia da atual escassez de eletrônicos, veja nossa compra da AMD Radeon E9172 MXM GPU (aproximadamente 295 EUR com IVA) e uma AMD Radeon E9174 MXM GPU (aproximadamente 380 EUR com IVA) em maio de 2021. A data de entrega prevista é 27 de novembro de 2021!
No momento, o custo das três placas MXM necessárias para os protótipos não são cobertos pela campanha de doação, mas pedimos seu apoio financeiro para elas também.
Enquanto isso, tivemos a oportunidade de comprar uma placa ATI Radeon HD4650 1GB DRR3 MXM 3.0 e, graças à gentil doação de Stefano, um novo colaborador da Itália, temos agora duas placas AMD FirePro M4000 GDDR5 1GB MXM 3.0A.
A ACube Systems, nosso parceiro que cuida da construção dos protótipos, também comprou um adaptador PCI para MXM. O adaptador nos permitirá testar as placas MXM antes de termos o protótipo pronto, pois ele será usado em conjunto com a placa-mãe “Sam460ex” feita pela ACube Systems. Os testes serão realizados sob AmigaOS 4.1, um sistema operacional PowerPC nativo.
Estamos estudando a possibilidade de atualizar nossa licença de Open Hardware de Cern 1.2 para 2.0.
A primeira coisa que notamos foi que a segunda versão está dividida em três variantes chamadas Strongly Reciprocal (S), Weakly Reciprocal (W) e Permissive (P). Basicamente, todos os três documentos são estruturados da mesma maneira e, na verdade, algumas seções são idênticas. As principais diferenças estão nas seções 3 Copiar, Modificar e Transmitir Fonte Coberta, 4 Fabricar e Transportar Produtos e 5 Pesquisa e Desenvolvimento (que não existe na licença Permissiva). As mudanças que podem ser encontradas comparando um documento com outro também implicam em conceitos diferentes a serem explicados na seção 1 Definições. A maioria dos termos que aparecem em mais de um documento tem a mesma definição. Exceções importantes a isto são 1.1 “Licença” que se refere à variante exata da licença em cada documento e 1.7 “Componente disponível” que não é exatamente o mesmo em R e W (e não existe em S).
Como entendemos, a variante deve ser escolhida dependendo das restrições relacionadas aos componentes (Componentes Disponíveis) e peças adicionais que poderiam ser adicionadas pelo Licenciado (Materiais Externos). A OHL-S especifica que toda “a Fonte Completa é a Fonte Coberta” e qualquer modificação deve ser distribuída usando a mesma licença. Por outro lado, a OHL-W permite a inclusão de Materiais Externos, o que significa que você pode adicionar algumas componentes ao projeto usando uma licença diferente. Finalmente, a licença Permissiva não menciona nada sobre Componentes Disponíveis e Materiais Externos, mas permite fazer ou publicar um Produto apenas incluindo todos os Avisos do Licenciador.
Para entender melhor as diferenças, os exemplos fornecidos na página FAQ do repositório Open Hardware são bastante explicativos:
No domínio de software, existem três regimes de licenciamento geralmente reconhecidos para software livre e de código aberto: permissivo, copyleft fraco e copyleft forte. Há preferências e casos para cada opção, e o mesmo acontece com o hardware. Usamos a palavra “recíproco” ao invés de “copyleft” porque os direitos subjacentes em nosso caso não estão restritos aos direitos autorais. Portanto, quando você usa a licença, você precisa adicionar um Aviso aos seus projetos com um dos três sufixos a seguir: S, W ou P:
O CERN-OHL-S é uma licença fortemente recíproca. Por exemplo, se você libera arquivos HDL sob o CERN-OHL-S e depois alguém usa esses arquivos em sua FPGA, quando distribui o bitstream (seja colocando-o online ou enviando um produto com ele) precisa disponibilizar o resto do design HDL também sob o CERN-OHL-S.
O CERN-OHL-W é uma licença fracamente recíproca. Considerando-se o exemplo acima, se você liberar sua parte do projeto sob o CERN-OHL-W, alguém que distribui um bitstream que inclui sua parte não precisa distribuir o resto dos arquivos do projeto também.
O CERN-OHL-P é uma licença permissiva. Permite às pessoas pegar seu código, relicenciá-lo e utilizá-lo sem qualquer obrigação de distribuir as fontes quando enviam um produto.
Em comparação com esta segunda versão, OSHL v1.2 não inclui os termos “Componentes Disponíveis” e “Materiais Externos”, o que dificulta o estabelecimento de uma relação direta com qualquer uma destas variantes. Isto nos faz pensar que provavelmente é mais similar à OHL-S.
Considerando a seção de Isenção de Responsabilidade, que é a que protege o Licenciador das questões legais e adverte o Licenciado sobre sua responsabilidade, ambas as versões têm uma escrita muito semelhante. A versão 2 é ligeiramente mais detalhada especificando que “O Licenciador não terá, na máxima extensão permitida por lei, nenhuma responsabilidade por […]” enquanto a versão anterior não mencionava os limites criados por lei. De qualquer forma, pensamos que estes limites são alheios e o significado da seção de Isenção de Responsabilidade é equivalente.
Mais uma vez, para comparar OSHL v1.2 e OHL v2, podemos fazer uso de uma pergunta na seção FAQ:
A versão 2 do CERN OHL melhora a versão 1.2 em vários aspectos:
A nova versão vem em três variantes: fortemente recíproca, fracamente recíproca e permissiva. As licenças recíprocas estipulam que as alterações de um projeto devem ser devolvidas à comunidade, para que todos possam se beneficiar delas. As licenças permissivas não impõem esta condição. Desta forma, o CERN OHL v2 atende aos diferentes modelos de colaboração atualmente utilizados em projetos de Hardware de código aberto.
Nas variantes recíprocas, é muito importante esclarecer o escopo das obrigações recíprocas. Ao introduzir os conceitos de “Componente Disponível” e “Material Externo”, mais o conceito já existente de “Produto”, a nova versão faz um esforço especial para esclarecer quais fontes devem ser compartilhadas tanto nas variantes -S como -W.
A versão 1.2 do CERN OHL incluiu uma licença de patente, ou seja, uma promessa do licenciante de que não processará um licenciado por violação de patente no que diz respeito ao projeto licenciado sob o CERN OHL. A versão 2 acrescenta uma cláusula recíproca para esta licença de patente: se um licenciado processar um licenciante por violação de patente, ele(a) perderá todos os direitos concedidos pela licença.
Na licença 1.2, não fizemos um esforço especial para atender ao desenvolvimento da Linguagem de Descrição de Hardware (HDL) como usada no Field Programmable Gate Array (FPGA) e no projeto de Circuito Integrado de Aplicação Específica (ASIC). Como ficamos convencidos de que não havia um regime de licenciamento recíproco apropriado para HDL, nos certificamos de que o CERN-OHL-S e o CERN-OHL-W podem fornecer uma boa solução para os projetistas de FPGA e ASIC com uma mentalidade recíproca.
A versão 2 faz um esforço especial para maximizar as chances de que o destinatário de um produto físico tenha acesso aos arquivos de projeto para esse produto. Isto é feito concedendo ao licenciante a possibilidade de incorporar uma URL ou outra referência no próprio objeto, e estabelecendo que os licenciados downstream devem respeitar esse aviso e atualizá-lo conforme aplicável se o projeto for alterado. Se eles entrarem em conformidade dentro de 30 dias após receberem uma notificação do licenciador, seus direitos são restabelecidos. Isto se destina a ajudar nos casos em que um licenciado infrinja os termos da licença inadvertidamente.
Estamos ainda estudando qual alternativa é melhor da OHL-S, OHL-W e OHL-P. A decisão deve levar em conta quão livres queremos que os licenciados sejam quando produzimos ou modificamos nosso projeto.
Participe de nossas palestras no OpenPower Summit 2021, Linux Day Online Italy 2021 e na Sfscon 2021
Para notícias sobre nosso projeto e planos futuros, participe de nossas conversas durante:
A partir de 22 de outubro de 2021, alcançamos 987 dos 1000 votos necessários para tomar uma decisão final sobre o nome da placa-mãe. Gostaríamos de fechar as piscinas assim que tivéssemos atingido esse número para começar a trabalhar na redação de logotipos e outros materiais de comunicação.
Incorporando suporte ao PPC64 Big Endian ao Freedesktop-sdk
Graças a Charles e Manuel, membros de nossa equipe de software, enviamos um pedido de incorporação ao Freedesktp-sdk de um patch para permitir a compilação no PPC64 Big Endian. Essa foi uma grande conquista e um enorme esforço de nossos voluntários. Um ótimo trabalho, pessoal! Muito obrigado!!
O Freedesktop-sdk estava prestes a cessar o suporte à arquitetura PowerPC por não ter um builder . A situação agora mudou, e estamos agora muito felizes em informar que mesmo graças à ajuda dos membros do OpenPower (da OSUOSL), em termos de atualizações e melhorias na branch ppc64le do freedesktop-sdk.
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.